[BZ 1141982] Readonly required props with defaults forced to same values
during bundle deployment.

In the case of new resource creation where the user has the
ability to enter an initial value for a readonly property. This is
not true with bundle deployment because the configuration object is
populated with the default values straight away. This is to make it
possible for the server-side bundle plugin to pass on some
information to the agent-side bundle handler.

This fix ensures that an update of such readonly property is not
possible either through UI or remote API.

In remote API we simply check the supplied deployment configuration
more rigorously, disallowing changes of any readonly properties from
the default values provided by the deployment configuration definition.

The UI had a clever logic of reusing configuration properties used
with the currently live deployment (if any). This approach generally
worked but was also updating readonly properties with the values
coming from the live deployment which is a wrong thing to do if we
understand the readonly props as a way of defining additional
metadata about the bundle version generated by the server-side plugin.
These should always be relevant to the bundle version being deployed
and not taken over from a deployment of some previous bundle version.

(cherry picked from commit 8ddc6ca38e45b6312fb7d903a5f9eef50cf068bb)
[BZ 1136945] Purge/revert of EAP patch bundles works more sanely.

To implement this reasonably, we started tracking the state of
patch bundles deployed through RHQ in external file, located under
the target Wildfly/EAP server's .installation/.rhq subdirectory (the
.installation directory is used by Wfly/EAP itself to keep track of
patching, so it is a logical place to add patching related information).

During deployment we determine the effective set of patches that were
applied from the patch file (by comparing histories before and after
deployment). We then use this information to revert/purge only the
patches that were deployed using RHQ. This information is stored per
destination in the above mentioned metadata directory (so that multiple
destinations per EAP are supported (even though such arrangement is
non-sensical)).

In another words all patches applied before a first patch bundle was
deployed through a destination are retained after a bundle purge and
the revert or purge of the bundle will fail or warn if the history
of patch deployment is unexpected (due to external patch rollbacks
or applications).

The revert/purge will fail if no patches can be rolled back due
to the state of the history having a different "tip" than expected.
A warning is emitted to the audit log if some of the patches that
were expected to rollback couldn't be because of some other change
in the patch application history.

There situations will only exist if the EAP server is patched through
other means than RHQ after it has been patched using RHQ thus creating
and inconsistency between what RHQ sees as the deployment history of
the destination and the real state on the EAP resources.

(cherry picked from commit d9beded5301ae12e2e20a00dc26c6e0e7cf80962)
[BZ 1069547] Adding "Active Patches" trait to Host ctl & Standalone svr

As such, the user now has the overview of the patches applied to the
individual Wfly/EAP servers in their env. This complements the bundle
subsystem from which the same information could be deduced, too,
under the assumption that RHQ server would be the sole "issuer" of
the patches to the servers.

(cherry picked from commit 5336d8c3380a8af3c8b9d73f4c2fc4da2c4e7a0a)
[BZ 1140578] Change the patch name delimiter also on the agent-side.

(cherry picked from commit 6f5c3811fd1d15e1ce76c53f82cb43ee07f6610f)