Improve support for conditionally-defined capabilities

Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request. 

Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally registered, we can use OperationContext.hasOptionalCapability() to check if it is actually registered. So consuming is easy but setting up is hard.

Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration.

Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK.

This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier.

FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate.