Improve sensitive expression handling

This is a follow-on to WFCORE-5305 and some of the issues discussed in https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/WFCORE-5305.20Issue. Specifically to what ReadAttributeHandler needs to when deciding whether to provide the resolved value for an expression to the caller. ResolveExpressionHandler should also be considered.

These handlers have problems because the expression resolution reads we are talking about occur in MODEL, but the capabilities needed to resolve expressions are not available until RUNTIME. (Deferring them to RUNTIME is a possibility, but that may have unwanted significant side effects.)

Some thoughts:

1) It seems wrong that these handlers are needing to guess whether a ModelNode/ValueExpression/String involves a security sensitive expression (i.e. one resolved from a vault or credential-store or some future equivalent.) Some central facility should be able to answer that question. And probably the OperationContext should expose an API that allows handlers to get an answer to that question with a single call.

2) We should clarify any distinction between determining whether a ModelNode/ValueExpression/String involves a security sensitive expression and actually resolving that expression. It is reasonable to restrict the latter to Stage.RUNTIME, as the services needed for resolution aren't available before RUNTIME. But can the check for the presence of a security sensitive expression be done during MODEL?

For the answer to this last question to be 'yes', the 'things' that can answer that question need to be made available to the mgmt kernel before any expression for which the answer is 'yes' is added to the config model. That means those things must be part of the kernel itself, or must be registered before any operations that involve resources that support security sensitive expressions are executed.

One possible cutoff point is to say such things must be registered before all /extension=foo:add ops complete. So registration of these 'things' could be done by the Extension impls themselves, via the ExtensionContext.

But that only works if for any 'thing' it is able to determine if the expression is security sensitive using data known when the extension is registered. So ${VAULT.....} works as that's a fixed string. But I suspect there is no equivalent pattern for credential store expressions.

Another possibility is to still register the 'thing' with the ExtensionContext, but allow Stage.MODEL handlers associated with the extension to update its state in MODEL. So, elytron knows it's adding a resource whose config means an expression ${ENC....} is sensitive. So its add handler updates the state of the 'thing' its extension registered. (NOTE: logically the 'thing' could be initially registered by the add handler via the OperationContext. The OperationContext API is already super-complex though. But that doesn't rule out using it.)

If that possibility was pursued, checks of whether an expression is sensitive that occur during boot should always return 'true' (or throw an exception), as there is no way to know during boot if all the 'things' are properly configured. Note that executing such checks during boot is an edge case. The handlers for the boot ops themselves have no need for such checks. Java agents that invoke management ops might make such calls during boot, but there's no requirement that they work.

An alternative to a lot of the above is to relax the restriction on accessing a capability's runtime API in Stage.MODEL. The basic reasons this restriction exists are:

a) the needed runtime services are not available during boot until RUNTIME, as parallel boot means subsystem A cannot count on things being registered by subsystem B during MODEL, as there is no reliable ordering between A and B.

b) after boot, within a single composite operation its possible step 2 in MODEL wants to utilize some functionality that step 1 will install in RUNTIME. But 2.MODEL executes before 1.RUNTIME.

This latter point is why allowing MODEL to access capability runtime APIs, but only after boot, seems like a bad approach.