[BZ 1069547] 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.
[BZ 1069547] 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.

* Rollback through operation - in case user would need special behavior
on rollback, they can use a dedicated operation on the AS7 standalone
server resource.

* 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.
[BZ 1069547] Fixes

* typo in CliExecutor.executeCliCommand preventing execution in
connected mode

* apply patches in disconnected mode when deploying through content
subsystem
[BZ 1069547] Removing support for patches from the content subsystem

This is to not overload the user with overlapping yet incompatible
choices for doing the same thing.

After discussion, we decided to keep the support for patching in the
bundle subsystem and drop it from the content subsystem.

This also means we need to drop the specialized rollback operation
because using that we could bring RHQ bundles into an inconsistent
state.
Merge 'origin/master' into bug/1069547
[BZ 1069547] Removing support code for rollback operation.

The operation has been removed from the descriptor in the previous commits
but I failed to also remove the backing code for its execution.
[BZ 1069547] Fixing the wrong schemaSpec number.

This comes from a wrongly resolved conflict in the db-upgrade.xml.
[BZ 1069547] Delete the downloaded files once not needed.
[BZ 1069547] Separate CliExecutor's concerns.
Merged pull request #80 from metlos/bug/1069547

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