implement release-pom.xml from design docs

My plan for implemetation (comments are welcome):

=============================================================================

MNG-607: release-pom handling

Goals
------------------------

PRIMARY

• Support fully reproducible builds for releases
• Support rebuilding releases from tagged SCM checkouts

SECONDARY

• Provide concrete information about how an artifact was created

Requirements
------------------------

• fully resolved release-pom.xml should be created in ${pom.build.directory}
  during package

• should EXPLICITLY define all information inherited/implied by the
  normal pom.xml, with no expressions.

• all RELEASE/LATEST/SNAPSHOT/range metadata should be resolved to
  concrete versions

• release-pom.xml should be archived in the artifact, rather than
  the original pom.xml

• release plugin execution should manage this release-pom.xml alongside the
  original pom.xml, and tag appropriately

• should be committed and tagged with the release

• should then be deleted before next (-SNAPSHOT) pom.xml version is
  committed

• execution of subsequent builds should try first to use release-pom.xml

• default over to pom.xml if non-existent

• NOTIFY the user when using release-pom.xml

• allow '-f' switch to force use of pom.xml (or other pom file) when
  release-pom.xml exists

Implementation
---------------------

• Add getFullyResolvedModel():Model to some sort of utility component
  (DefaultMavenProjectBuilder, MavenProject, etc. ?)

• sort through plugins and resolve to concrete version

• sort through dependencies and resolve to concrete version

• remove dependencyManagement and pluginManagement (not used in
  fully-resolved scenario)

• cache this Model instance for later reuse?

• Change MavenArchiver to use ${project.fullyResolvedModel} for the bundled
  pom.xml in META-INF
  
  * Change release plugin to write, tag/commit, delete, commit release-pom.xml
  using ${project.fullyResolvedModel} to ${basedir}/release-pom.xml.

• Modify MavenCli:

• pickup on release-pom.xml if it exists, and NOTIFY THE USER that it's
  using that pom.

• provide '-f' switch for explicitly specifying which pom file to use (for
  overriding release-pom.xml selection)

Plan of Attack
-----------------------

1. Implement getFullyResolvedModel():Model with caching in MavenProject

2. Modify MavenArchiver to use fully resolved model in META-INF

3. Modify MavenCli to support '-f' and choice of release-pom.xml over pom.xml

4. Modify release plugin to support management of release-pom.xml

MavenProject is not the right place for getFullyResolvedModel(), which also means that the method name is not the best. I'll hunt for another home/name for it...

comments:
" - cache this Model instance for later reuse?"
I don't think this is necessary

"* Change MavenArchiver to use ${project.fullyResolvedModel} for the bundled
pom.xml in META-INF"
it should store pom.xml (the original) and release-pom.xml, IMO. As I understood it, it already did this, so it would be worth checking it first.

" - provide '-f' switch for explicitly specifying which pom file to use (for
overriding release-pom.xml selection)"
users will also use this to other files than pom.xml (even if it isn't recommended), so make sure you can do directory relocation (ie m2 should run from the same directory as the file). See Maven 1's CLI.

95% complete. Need to switch to newer version of maven-scm to allow us to use a remove command in order to delete release-pom.xml from the HEAD/trunk.

I'll revisit this once I've talked to Emmanuel, and he's done with API changes for maven-scm.

resolving the remaining release plugin issues in MNG-662