Provide a means of replacing one mojo binding with another, without knowing the location of the first binding in the lifecycle

Lifecycle phase-bindings that are inherited from parent POMs or packaging-mappings are invisible to the user, without sometimes extensive research into the POM lineage and/or the extension artifact source that brings in the packaging-mapping.

For end users in a large development environment, it should be possible to replace an inherited mojo binding with one specified in the local POM, without needing to know what phase that binding is attached to. It is possible to see the full mojo ID and execution ID for a replacement target in the debug output of a build, but phase transitions are not logged...which makes researching the phase-location of a mojo binding quite difficult. Replacement should be available at either the execution level, or the mojo level within a specified execution.

If replacing a mojo in the lifecycle mapping given by the project's packaging, the executionId for the replacement should be 'default'.

This feature should be accompanied by a new mojo in the help plugin which can print out the effective build steps in that project's lifecycle, to help with debugging replacements, etc.