Rethink the system of configuration and properties with narrowing the API

With the growth of integrations of Narayana into various runtime, it would be good to think about the appropriateness of the configuration of Narayana via different beans and usage of reflection. The use of the reflection is especially pain point for Quarkus runtime as it decreases the startup time significantly.

There is a quick fix for reflection usage as the issue JBTM-3214 and the discussion was run at the PR of the issue at https://github.com/jbosstm/narayana/pull/1521.

Narrowing the API: the JBTM-3214 opens the `BeanPopulator` class create the bean class during the startup. With this change comes a possible trouble if multiple libraries tries to define the class during the startup. The one which creates and executes the bean or first one which grabs the bean defines the configuration. The following code which would try to setup the configuration will not be able to do so. Only the first setter is considered.

Then possibly a single mechanism for configuration could be considered. For example we can have definition that says that all beans are for configuration from the XML (then reflection and xml parsing are done) or all beans are configurable with an external provider (no reflection and xml parsing).
The `BeanPopulator` would then not having any `setter` but only `getters` (as it was until JBTM-3214) and the global configuration property will configure if reflection and XML parsing will be used or not.

There is another point to consider. The Narayana configuration suffers with trouble of using `TxControl` class which is statically defined and when it's defined for the first time then change of configuration is harder. The developer needs to touch first the bean and as the second thing he needs to change the value owned by the `TxControl` class.