release-approval: Shuffle to make more DRY

[wking]

Avoid duplication by collecting common ideas (e.g. list-based voting)
in their own sections. After this reshuffling, it became apparent
that there were no special application restrictions, so I added
additional language to motivate the specification-specific additions.

[philips]

@wking This is a big improvement, thanks! The applications do have a special process though: they require a release sponsor, co-sponsor and only one person LGTMing. So a release can be made with only three people involved:

"OCI application projects MUST announce intentions to release with two project maintainer sponsors on the [email protected] mailing list. After the announcement at least one more project maintainer MUST reply to the list with an LGTM within one week for the release to be approved."

[wking]

On Thu, Jun 16, 2016 at 10:57:15PM -0700, Brandon Philips wrote:

@wking This is a big improvement, thanks! The applications do have a
special process though: they require a release sponsor, co-sponsor
and only one person LGTMing. So a release can be made with only
three people involved:

I'm not really a fan of that (if 1/3 of your maintainers can't be
bothered to vote on a release, I think it's time to start firing
maintainers ;). “A bunch of our maintainers are lazy” is solvable
(kick them out), but “what, you cut that terrible release while the
rest of us were at DockerCon” is harder to undo.

However, hopefully both are unlikely ;). So language added in 77305d8
→ 9a388bf.

And feel free to squash/reroll/whatever these commits.