ResolveExpressionAttributesTestCase tests that the XML subsystem expressions can be resolved.

Right now, it is just using the ModelNode ValueExpression to resolve the expressions read from the XML subsystem markup under test, see for example:

[ResolveExpressionAttributesTestCase.java#L494|https://github.com/wildfly/wildfly-core/blob/04f9193b371f969ec06faed7e9b6bd65ab24126d/elytron/src/test/java/org/wildfly/extension/elytron/ResolveExpressionAttributesTestCase.java#L494
]

 ModelNode result = node.get(attributeName).resolve();

This is weak because it is just testing that the ModelNode object is able to resolve expressions based on its ValueExpression. 

It would be better if, instead, the server were the one that resolves the subsystem expression based on its own logic (which could be the same as the current one being tested) and returns the ModelNode already resolved.

By doing that, we will be testing how the server resolves this specific subsystem and not just how the ModelNode resolves the expression. That will make the test more robust to test server code changes.

An example of this approach can be found at https://github.com/wildfly/wildfly/blob/main/naming/src/test/java/org/jboss/as/naming/subsystem/NamingSubsystemTestCase.java#L113-L117:

        final KernelServices services = createKernelServicesBuilder(createAdditionalInitialization()).setSubsystemXml(readResource("subsystem_expression.xml")).build();
        final ModelNode addr = Operations.createAddress("subsystem", "naming");
        final ModelNode op = Operations.createReadResourceOperation(addr, true);
        op.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(true);
        final ModelNode result = services.executeOperation(op).get("result");

There, the model is read with the expressions resolved, we have to do something similar to read the whole server model already resolved at the init() method, and use that new serverModel to assert the expected values