Prepare for Maven release
promoting released artifacts and closed staging
removed settings.xml, updated building-junit.txt and pom.xml
public GnuPG key 67893CC4
-Dtag=4.12
removed "Update SNAPSHOT version in pom.xml" "Upload stuff to github (including tag)"
Apply the canonical ordering of pom.xml elements

* You are not required to use the canonical ordering, but it makes it easier if you
  follow the conventions and follow it.
Only use a property where multiple entries need syncing

* The hamcrest version is only used in one place, i.e. the dependency.
* Using properties to define dependency versions can cause issues for others.
* Using properties to define a shared version across multiple dependencies causes less issues
  when you have multiple dependencies that need to be kept in sync.
* We only have one dependency here and it doesn't need syncing to any other dependency
* Therefore the right thing is to just specify the version in the dependency
* End users can still override the dependency in their poms.
Make the release plugin generate tags according to JUnit convention

* JUnit has been using r4.xx as the tag format
* Maven Release Plugin would, by default, use junit-4.xx as the tag format
* Maven has no strong opinion on the tag, just providing a sensible default
* The Maven way is to follow convention, JUnit has the precident convention with existing tags
GPG signature should be generated prior to 'install' phase.

* There can be issues for the local repository if the signature happens after the install
  to local repository cache.
* Only people with the GPG key should be running with the 'junit-release' profile active
* Therefore safer to move the execution to the 'verify' phase
Allow tweaking release arguments form the CLI

* We need to provide a default empty value for the 'arguments' property within the pom
  This ensures that when the property is not provided, the build can still continue
* The `arguments` property is especially useful if you don't have the GPG key for
  signing as you can then test the release process by adding

    -Darguments=-Dgpg.skip=true

  to the command line used to prototype a release and the verification build will succeed.
update the building docs

* When running  there is no need to do a  first

* Add some docs for people who need to maintain an in-house fork.'
Actually allow forkers to sign their own releases

* If you run an internal repo, you may be required to have signed artifacts
  So to make their life easier, use a property to define the default signing key
  Allows for others to swap in the key they use via the -Darguments=-Dgpg.keyname=
  trick
Move the javadoc configuration to the default.

* Making the configuration of javadoc tied to the execution makes it harder for
  people to tweak the javadoc configuration as they have to invoke the lifecycle
  rather than just invoke 'mvn javadoc:javadoc' to see the effects quickly
Move javadoc:jar and source:jar to the release profile.

* Only need to be generated when cutting a release or deploying a -SNAPSHOT remotely
* In those remote deploy situations -Pjunit-release will be active anyway
* Moving them out of the main build speeds up development for all
Move the generating documentation to a separate profile

* Given that this profile is for a specific purpose it does not need to be namespaced
* The release profile needs namespacing as it is used from settings.xml also which
  is cross project. There should be nobody using a profile called generate-docs to
  activate their release GPG credentials
Add issueManagement and ciManagement
Merge pull request #614 from stephenc/junit.reopen

Tweaks on pull request https://github.com/KentBeck/junit/pull/613