Enable fabric8:deploy for Mule Apps (1.x) (Correct branches!)

This is the same as PR #2783 but pointed at the 1.x branch. Original description follows:

This is a revision of PR #2740. I’ve revised the description of this PR because the original was probably a bit hard to follow.

To make fabric8:deploy work with the mule example we have to do several things:

* Use the artifactBundleType and Classifier parameters in fabric8:deploy, just as we did for the zip goal.
* It turns out that the ‘type’ of the root dependency in requirements.json also has to be consistent with the fabric8 agent properties, otherwise an error will be thrown in the agent as it will see separate dependencies to resolve from both config files. It will be able to resolve the ‘zip’ type but not the ‘mule’ one.
* Modify the deploy mojo so that it is capable of finding attached artifacts (not just the primary artifact). Previously, since it was forking a lifecycle to do the install phase, the deploy mojo could not find the attached artifact since it gets a separate project object. This was resolved by injecting the [‘executedProject’](http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations) from the forked lifecycle (to use maven terms). [Mule zips are attached artefacts](https://github.com/zenlambda/maven-mule-plugin/blob/master/src/main/java/org/mule/tools/maven/plugin/MuleMojo.java#L106).
* Un-Apply the exclude artifact work around in the example (which effectively disables deployment) and apply the new maven parameters instead.
* Introduce an option to omit dependencies from the requirements.json, which is useful when the artifact is itself self contained (non-provided dependencies are already in the zip).
* Update ArchetypeTest to correspond with the change to the fabric8-profile parameter. I use the test to verify the mule example. Without this change the test is broken and will not work with any archetype.

Documentation and tests are included for the new ‘omit dependencies’ maven property. The tests use the invoker plugin since we need maven’s help to build a dependency tree.

Additionally this PR addresses an issue with the maven unit tests where stub poms where pointing to the wrong code. This led to the discovery the that packaging types also affect url and key prefixes for the deployer. I corrected the tests accordingly.

This may seem like a big PR but the only active code it changes are the main maven mojo.

* AbstractProfileMojo.java
* DeployToProfileMojo.java

The rest is just testing :-) .