[PROPOSAL] Introduce a new LLVM process to resolve contentious decisions

[RE: adding an RFCs/Proposals mailing list] I'm not enthusiastic about this and would rather avoid it. Adding a new mailing list is potentially acceptable as long as the rule is that proposals **must** be cross-posted to the relevant project mailing lists. E.g., if we have a proposals@lists.llvm.org, any proposals affecting LLVM itself must also still go to llvm-dev@lists.llvm.org.

I would actually argue that the rule should be that RFCs **must not** be cross-posted anywhere but the RFCs mailing list. My reasoning for this:

1) In my opinion, anybody interested in driving the overall design of the project should be subscribed to the RFCs mailing list, so they will see the RFCs.
2) The before-mentioned "you are not subscribed to this mailing list" issue. When messages are posted to n different mailing lists, you often get n-1 rejection emails. Realistically, many people are not going to go subscribe to the relevant mailing list and resend, they're just going to say "well, I guess the [whatever project] folks aren't going to see that one".
3) It will reduce noise. This will mean that other types of messages get higher visibility in their respective mailing list as they won't have to compete with 30 different replies to "RFC: The bike shed should be green".
4) It ensures that everybody who cares about RFCs (as defined by "you would be subscribed to the RFCs maling list if you care about RFCs") will see every RFC. Often, some RFC will be churning along in cfe-dev, then get cross posted to llvm-dev. Then, since not everybody is subscribed to both of those mailing lists, many people will only see parts of the conversation as some messages will get put in the mod queue for one or the other, never to be seen again.

I do agree that the RFCs mailing list should not bounce any messages. Is it possible to configure it to skip the moderation queue if the sender is a member of any llvm project mailing list?