Improve and clarify the core committer signoff process for changing coding standards

Problem/Motivation

• Step 7 of the process for changing coding standards currently says:
  

  If the issue affects core it will be moved to the core queue and marked RTBC for core committer signoff after which the issues should be left in RTBC, tagged with “Core Committer Approved” and moved back to the coding standards project queue.

  For background on why this step exists, see #2428153-39: Create and document a process for updating coding standards.

• At the time we created this step, we didn't know what core committers would require in order to approve a coding standards change. Since then, we've learned that what they require is:
  1. To sign off on the idea, which requires information on how core currently deviates from the proposed standard and what changes would be needed to comply.
  2. For a rule or rules to be added to Coder for automated testing of core compliance.
  3. For the development branch of core to be patched to comply, the Coder rule(s) enabled, and the change tagged for the branch's release notes. For disruptive changes, this can sometimes be postponed until a beta or RC phase of the development branch.
• We'd like to increase the visibility of where in the above 3 steps a coding standards change issue is.

Proposed resolution

???

Remaining tasks

Provide a proposed resolution.