Reform the RFC process

[adpaco-aws]

In this PR we propose a new version of the RFC process. The goal is to make the process simpler (only four stages), and decouple the implementation status from the RFC's so that the implementation, models and testing for any feature are all at the same level.

In particular, we have identified the following problems with the current RFC process:

1. Analyzability is not exercised until late in the process despite being a requirement for most features. It’s the main reason new designs were needed in the case of RFC 68 and its predecessors.

• The purpose of the two “Experimental” states is to declare that there may be an experimental Rust implementation. This is a detail that shouldn’t require its own state.
• The purpose of the “FCP” state is to declare that it will be accepted/rejected unless there are new concerns/discussions. This could just be the “Pending” state with an “FCP” label (i.e., a sub-state).

Another advantage of this proposal is that, when an RFC is accepted, it becomes "Unstable". This communicates a state that is not desirable for users to depend on. Requirements for stabilization remain the same, forcing developers to provide implementation, models and testing for any stable feature.

In summary, these are the changes included in this PR:

• Edits for version 2 in README.md (including new flowchart).
• Small edit for version 2 template.
• Move the RFC process v1 to a new folder archive/process-v1.
• Edit timelines in previously committed RFCs to refer to the RFC process v1.

Rendered