CG: incomplete docs for procedure for issue resolution after pushing to staging

[Adam Spiers]

Whilst the procedure of marking an issue as fixed, with an additional
Fixed_mm_MM_ss label, is briefly mentioned at the end of the "Issue
classification section" in the Contributor's Guide:

    http://lilypond.org/doc/v2.17/Documentation/contributor/issue-classification

it is slightly misleading, and also omits important details:

  - Fixed_mm_MM_ss suggests fixed width, e.g. Fixed_02_17_01, but this
    is not the case.  It would be better to call it Fixed_X_Y_Z.

  - What's the correct value of X, Y, and Z?  (Answer is presumably
    that they come from MAJOR_VERSION, MINOR_VERSION, and PATCH_LEVEL
    in $LILYPOND_GIT/VERSION)

  - Are developers supposed to mark the issue as fixed immediately
    after pushing the corresponding patch series to staging, or should
    they first wait for the tests to automatically advance master?

Additionally, the above information still needs to be explicitly
referenced from the two[1] places where pushing to staging is
documented:

    
http://lilypond.org/doc/v2.17/Documentation/contributor/git-for-the-impatient
    http://lilypond.org/doc/v2.17/Documentation/contributor/pushing-to-staging

I think it would be better to reference via links back to the 'Issue
classification' section, rather than have the same information
duplicated three times.

Thanks,
Adam

[1] Speaking of duplication, why do we document the procedure for
pushing to staging twice?  The version in 'Git for the impatient' is
hardly any shorter than the full version in 'Pushing to staging', and
violating the DRY rule increases the maintenance burden and also risks
information becoming out of date in one of the two places.  Should
impatient git users even be allowed to push to staging?