BZ 1069547 / JON3-10  Support EAP 6.2/6.3 style patching

This PR is separated into 2 commits, the messages of which detail the changes in them:

## Support for API-based bundle handlers

This is to support new type of dedicated bundle handlers able to do more than just file-system modifications. In order to enable them to e.g. connect to some remote endpoint, a more complex configuration data needs to be passed over.

This creates coupling between the bundle destination definition and the handler that is able to deploy to such destinations (because it needs to be able to use the configuration offered by the destination definition) but that is unavoidable given the specific things the handlers would be doing.

* The resource types can use the new "destination-definition" tag under bundle target to define new type of destinations that can use a "connection string" expression + can pass all or parts of resource or plugin configs or traits to the bundle handler.

* The agent-side bundle handlers have access to the bundle deployment configuration even in the purge scenario. This is to support the more complex bundle handlers needing the config to better identify the bundle deployment.

* The deploy directory is no longer a required argument when creating a bundle destination. This is because for the API based bundle handlers, such configuration property might not make any sense and would only create confusion on the user side.

* It is no longer required for the server bundle plugins to come up with the full list of the required files upon reading the recipe alone. The bundle plugins can therefore choose whether they support piece-wise
upload of the bundle version or only support uploading a full bundle distribution file.

## Wildfly patching by various means

* **Bundles** - using a dedicated bundle type. This enables us to understand the patch zip file as our bundle without any RHQ specific recipe. We can supply various parameters to patch application process but although revert is supported, it cannot be configured by any parameters as one can do over Wfly's CLI.

* ~~**Content** - patches appear as packages of the AS7 standalone server. They are discoverable and can be installed from repositories (without any possibility of customizing the install process). Delete (i.e. rollback) is supported, again without configuration.~~
This has been dropped to simplify the choices and also to lower the possibility of mutual confusion of the subsystems when used together.

* ~~**Rollback through operation** - in case user would need special behavior on rollback, they can use a dedicated operation on the AS7 standalone server resource.~~
This has been dropped to not confuse the bundle subsystem.

* **Bundle handover** - patches can be installed using the bundle handover facility, too, using the "patch" action. This is configurable using handover parameters and supports all the parameters available in Wfly's
CLI.

One needs to pass a bundle version ID to this method so the recipe must have already been parsed. So in case of bundle types prior to this change, this should never fail (and that's why the exception was not handled in this method at all).

Now with patches, we are not able to determine the bundle files from just the recipe (we ARE able to do that when parsing the full distribution file). So the conclusion here is that the bundle version has been created correctly and therefore the bundle recipe or the bundle distribution file (depending on the bundle creation method and bundle type) must have been parsed and processed OK.

If the bundle type doesn't support recipe-only bundles (which patches don't) it has no option but to fail in the parseRecipe method - it doesn't have enough info to provide all the data in the parse results. But the bundle version must have correctly been create prior to this method call so the bundle is kinda ok. Hence returning empty collection and logging on debug seemed OK to me.