[MEP process] Define separate proposal and implementation stages

[mmcky]

Here are some thoughts I have re: possible updates to the process:

A full technical implementation can feel onerous to contributors before suggesting a change, as you can end up spending a lot of time building something that might get rejected. Perhaps we could introduce three stages to allow ideas to be pitched and discussed to get a strategic direction before the full investment in a reference implementation.

Perhaps we could adopt a traffic light style 3 stages for full acceptance.

• Approved - Would appear in the MEP list of changes to give community notice and enable bigger changes (like this) time for a reference implementation but knowing the community agrees with the change and the planned direction.
• Technical - build and ensure Syntax works and/or change can be implemented, revise MEP if any minor issues develop due to performance degradations, or unforeseen complexity.
• Accepted (or Cancelled) - Accepted is the formal inclusion in a version release of the spec. I think cancelled would be used very rarely only if major technical issue arose.

In the context of this MEP, once merged the status would be:

🟢 Approved
🟡 Technical
🟡 Accepted

In the context of smaller MEPs all three could be achieved in a single merge process.

[choldgraf]

Just noting that Jupyter's enhancement proposal process has a separate stage for implementation. Discussion and approval happens at the JEP proposal stage, and if accepted, it creates "permission" for any stakeholder to suggest an implementation. We could follow something similar here, and then consider a MEP only "complete" once it has been implemented.

I think that would imply that we only need one extra step rather than two. Once a MEP is approved from the core team, it is

🟢 Approved
🟡 Implemented

And once an implementation exists (that links to the MEP PR for reference) it is

🟢 Approved
🟢 Implemented

For some MEPs the core team might decide that an implementation is a pre-requisite for approval (e.g. to prove out feasibility) and that would be their call.

For some MEPs an approval might happen, but then we run into unexpected issues at implementation, and this could re-open the "approval" phase for edits and/or rejection.

I think this would imply adding another section to #31 to add something like:

## PR for implementation

- _link to PR_