Proposed Interledger RFC process

As discussed before we have an issue whereby our Interledger RFCs are
regularly changing and it's not possible for someone to refer to a static
version of the document and be sure that the content won't substantially
change the next time they visit the URL.

I had initially proposed that we introduce semantic versioning on the RFCs
but we decided against this on the basis that we should:

a) Differentiate between specs that are incubating (similar to IETF
Internet Drafts) and those that are mature (similar to IETF RFCs)
b) Assign an RFC number to stable specs and a new number to revisions of
that

As such my proposal is that we adopt the following process for the
Interledger RFCs going forward (this is something of a hybrid between the
IETF and W3C processes and is in keeping with the process defined for us as
a W3C Community Group):

1. There are two document types *Working Drafts* and *Candidate
Specifications*.
2. Interledger RFCs are living documents that start as *Working Drafts*.
3. Working Drafts have an RFC number AND a draft number starting at 0 and
increasing by 1 each time the content is changed. Attempting to merge
changes to a Working Draft without incrementing the draft number should
result in a build failure of the publishing process.
4. When a *Working Draft* is considered stable there is a call for review
from the community to publish the document as a *Candidate Specification*
5. Assuming there is consensus to publish, the document becomes a *Candidate
Specification* and no further substantive changes are allowed under the
same RFC number.

NOTES:

   - Candidate Specifications SHOULD also be published as W3C Community
   Group reports.
   - Candidate Specifications MAY be published as IETF Internet Drafts.
   - A different template should be used for Working Drafts and Candidate
   Specifications to help readers differentiate between them.
   - An explanation of this process should be available on the website and
   linked from the RFCs