Change ACP process to track unimplemented ACPs

[pitaj]

Currently, the ACP process works like this:

1. An ACP is submitted proposing some API feature
2. The ACP is reviewed in a team meeting or directly by a team member
3. If rejected, the ACP is just closed
4. If accepted, the ACP is closed after adding the ACP-accepted label

This process has no feedback on whether the API feature is actually implemented, which is problematic because there is no easy way for contributors to find ACPs to work on.

We propose to change the process to this instead:

1. An ACP is submitted proposing some API feature
2. The ACP is reviewed in a team meeting or directly by a team member
3. If rejected, the ACP is closed after adding an ACP-rejected label
4. If accepted, the ACP-accepted label is added
5. Once implemented, the ACP is closed with a comment linking to the tracking issue

This allows someone to find accepted but unimplemented ACPs by searching for open issues with the ACP-accepted label.

Alternatives

One alternative is, instead of leaving the issue open, apply two labels when accepting it: ACP-accepted and unimplemented. When the ACP is implemented, the umimplemented label is removed.

This option may work better with triagebot. I'm not sure if we can set it up to allow just anyone to close issues, but we can set it up for anyone to change labels. It also requires less modification to existing tools, like the agenda-generator.

But it's less clean and less discoverable. Closing an issue typically means that no work is left to be done, but that isn't true for unimplemented ACPs.

What needs to change

• Issue template: add some verbiage that describes what will be done when an ACP is accepted and what needs to be done once the API is implemented.
• Agenda maker: modify to exclude issues labeled as ACP-accepted