BZs 1136996 1135034 1135107 - Check if patching is supported before trying to perform it on EAP based resource

In the end, this feature is quite simple yet is still described by 3 BZs and is implemented in 2 commits.

The first commit adds support for `ResourceUpgradeCallback`. This mechanism is similar to `ResourceDiscoveryCallback` (and in fact is more or less a shameless copy&paste of it) and enables 3rd plugins to modify the results of the resource upgrade in the similar way discovery callback impls can modify the results of discovery.

This is to complete the picture of such out of band modifications of resource details and plugin config. If we are able to modify how a resource is discovered, we should also be able to modify how a resource is upgraded so that pre-existing resources can have the same treatment as the newly discovered ones.

The second commit uses this new functionality to introduce a new plugin config property of EAP server - `supportsPatching`. The AS7 plugin can set this value automatically based on the version and product type but it would set a wrong value for RHQ server because it advertises itself as an ordinary EAP. This is where the new `ResourceUpgradeCallback` and `ResourceDiscoveryCallback`, implemented in the RHQ server agent plugin, kick in and correct this value.

Finally, I purposefully chose to use plugin configuration for storing this attribute even at the cost of the user's need to manually update this value when upgrading manually from non-patchable version of EAP to patchable.

The other option was to make this a trait. But traits have an unfortunate time window where  the value of them cannot be obtained if the resource is down AND the value was not yet collected by the agent. The PR #116 mitigates that somewhat but the window still exists. Also traits lack the support for out-of-band changes of the collected values like it is possible with `Resource(Discovery|Upgrade)Callback` and thus it would be hard if not impossible to distinguish the odd-balls when it comes to patching (like RHQ) without resorting to hardcode the knowledge about them into the generic AS7 plugin.

Why an _xs:choice_ here? To be able to declare the attributes in any order?