Add config options to change labels for draft/closed/reopened PRs

[WaffleLapkin]

Adds the following options:

[autolabel."<label>"]
reopened_pr = true
new_draft_pr = true
reopened_draft_pr = true

[converted-to-draft]
remove_labels = []
add_labels = []

[ready-for-review]
remove_labels = []
add_labels = []

[closed-pr]
remove_labels = []
add_labels = []

[WaffleLapkin]

This actually makes me think that using label <-> filters map makes little sense. Maybe a label actions, filters would be more appropriate?

Something like

[[autolabel]]
new_pr = true
add = ["S-waiting-on-review"]

[[autolabel]]
review-submitted = true
reviewed_label = "S-waiting-on-author"
review_labels = ["S-waiting-on-review"]

[[autolabel]]
review-requested = true
remove_labels = ["S-waiting-on-author"]
add_labels = ["S-waiting-on-review"]

Instead of

[autolabel."S-waiting-on-review"]
new_pr = true

[review-submitted]
reviewed_label = "S-waiting-on-author"
review_labels = ["S-waiting-on-review"]

[review-requested]
remove_labels = ["S-waiting-on-author"]
add_labels = ["S-waiting-on-review"]

The advantages are:

1. Doesn't require new systems for every event
2. Can bind multiple labels for the same events
3. Can bind labels to multiple events at the same time

Example of the last point:

[[autolabel]]
# Positive filters require any positive filter to fire, i.e. this is triggered on either event
review-requested = true
ready-for-review = true

add = ["S-waiting-on-review"]
remove = ["S-waiting-on-author"]

[WaffleLapkin]

The only question is how to make this in a backwards compatible way...

[jackh726]

To give feedback on the best approach, can you explain a bit on what you want from this?

[WaffleLapkin]

@jackh726 I want to improve the way we handle draft PRs. Specifically there are 3 things:

• PRs opened as drafts
• PRs converted to drafts
• PRs marked as ready for review

Currently they don't have any special handling. This is a bit awkward because drafts are marked as S-waiting-on-review, etc.

Since people know how to use github features and occasionally do use them in rust-lang/rust, I want to support them in @rustbot, so that for these cases we don't need any intervention (changing labels, etc).