Clarified handling of staging branch in branching scheme documentation

[Michael Jumper <mj...@apache.org>]

With 1.6.0 progressing and the usual dependency updates underway, I 
noticed that the previous branching scheme documentation is incorrect 
with respect to handling of changes tied to a release while the staging 
branch for that release exists.

I've updated things to clarify:

* The "patch" branch represents the next possible patch release that
   is not yet being staged.

* The "main" branch represents the next possible minor release that
   is not yet being staged.

* The "next" branch represents the next possible major release that
   is not yet being staged.

Thus, after 1.5.5 was released:

* "patch" represented a possible 1.5.6 release.
* "main" represented a possible 1.6.0 release.
* "next" represented a possible 2.0.0 release.

And now that "staging/1.6.0" has been created off "main":

* "staging/1.6.0" represents the 1.6.0 release being prepared for RC.
* "patch" represents a possible 1.6.1 release.
* "main" represents a possible 1.7.0 release.
* "next" represents a possible 2.0.0 release.

Additionally, the documentation had stated that changes to the staging 
branch should be merged back to whichever base branch originated that 
staging branch, but this is incorrect and will result in the branches 
getting out of sync. The staging branch should *always* be merged back 
to "patch" such that it correctly represents whichever patch release 
would follow the release being staged, and then those changes can be 
merged back to the other branches following the usual cascade of merges. 
In the case of a major or minor release, this would include merging the 
staging branch back to "patch" after the staging branch is created.

https://cwiki.apache.org/confluence/display/GUAC/Version+Numbering+and+Branching+Scheme

- Mike