Layers for core-galleon-pack

In order to take benefit from galleon layers feature, the core galleon feature-pack should define layers that could then be used to build custom installation. The layers are not intended to be exposed as a public contract, they are an implementation detail allowing for internal custom provisioning.

We are proposing:

1) Define a set of core layers that target standalone kind of configurations. Layers have no dependency on legacy security realms, security aspects are handled using elytron. Patching is also not covered by layers.
List of layers:
base-server
core-management
deployment-scanner
discovery
elytron
io
jmx
jmx-remoting
logging
management
secure-management
remoting
request-controller
security-manager
core-server (aggregation of base-server, elytron, secure-management, jmx, jmx-remoting, logging, core-management, request-controller, security-manager)
core-tools (all core management tools).

2) Express the default standalone configuration by a set of layers. The default configuration based on layers would be identical to the current one (based on feature-groups). feature-groups are the place where feature configuration occurs, layers are referencing feature-groups. The default configuration extends layers with legacy security aspects.

3) domain kind of configurations are not impacted by layers.

4) In order for galleon to be able to only provision the set of modules required by layers and not provision all server's modules, the management API must evolve for server and extensions to express dependencies on modules that are not part of their module.xml required dependencies (eg: modules that are injected in Deployment units).

5) This management API would then be used by server and subsystems. The impacted core resources are root-resource, elytron, jmx, remoting and logging.