Issue title: Reorganize issue/PR labels
 Issue body: This repo currently has the following [labels](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/labels) available: 
* `Component: Docs`
* `Component: Extras`
* `Component: Templates`
* `Component: Upstream`
* `Component: VIP Blocker`
* `Component: VIP Caution`
* `Project: auto-fix WP Core / trac-41057`
* `Requirement: phpcs 3.x`
* `Status: Awaiting Feedback`
* `Status: Duplicate`
* `Status: Invalid`
* `Status: Investigation`
* `Status: Maybe Later`
* `Status: PR Exists`
* `Status: PR Required`
* `Status: Review Ready`
* `Status: Wontfix`
* `Type: Bug`
* `Type: Chores`
* `Type: Cleanup`
* `Type: Documentation`
* `Type: Enhancement`
* `Type: Modern PHP`
* `Type: Question`

I'd like to propose to make the following changes:

### Add labels
* `Component: Core` - While the other rulesets each have a Component label, the `Core` ruleset does not, so this label should be added.
* `Meta` or `Repo: meta` - questions about the repo strategy, repo structure, release schedule, dependency minimum version changes, and for instance, this issue itself, are more "meta" questions and there's currently not a good label available to tag these with.
* `Status: help wanted`, `Status: good first issue` - both of these (without the `Status:` prefix) are standard labels which are created by default nowadays for new repositories. They are widely recognized and help new contributors find issues which could be a good fit for them.

### Rename labels
* `Component: Upstream` - PHPCS upstream is not a component of this repo, so I'd like to propose renaming this label to `PHPCS: upstream`.
* `Requirement: phpcs 3.x` should probably be changed to `Requirement: higher phpcs version` or `Requirement: dependency change` - as that way the same label can continue to be used, even when it would become `phpcs 3.3.x` or `phpcs 4.x` in the future or if more dependencies are added, it can be (re-)used for those too.
    The label basically involves anything for which the minimum supported version of a dependency would need to be raised.

### Remove labels
* `Component: Templates` - No idea why this label was ever added.
* `Component: VIP Blocker` - as the VIP sniffs are slated for removal and the VIP CS checks are now contained in their own dedicated repo, this label is superfluous.
* `Component: VIP Caution` - same as above.
* `Project: auto-fix WP Core / trac-41057 ` - The label is a bit of an odd one out and has been superseded by the initial trac ticket being closed now. To still keep an overview of everything what happened because of this, we should probably add a GH project (feature didn't exist at the time) and add that project to the issues tagged with that label instead.
* `Status: Investigation` - Basically, if something is being investigated, someone should be (self-)assigned to the issue, so it is clear that someone has taken ownership of the ticket. If nobody is assigned, who is doing the investigating ?
     Alternatively, the label could be renamed to `Status: Needs investigation` which would more clearly indicate that the issue is up for grabs.
* `Status: PR Required` - basically any issue which is open and not awaiting feedback/invalid, requires a PR, so this label seems superfluous to me.
* `Type: Cleanup ` - the issues here are typically also `Chores`, so I would suggest relabeling them to `Type: Chores` if they don't already have that label. `Chores` covers more than just `Cleanup` which is why I think that's the better label to keep.

### Potential new label category:
* `Priority` with label `Priority: High` - High priority issues should be fixed in the very next release. Any issue which doesn't have this label has "normal" priority.
* Potentially a `Priority: Low` label could also be added to indicate that those issues can be ignored until further notice. In that case, the `Maybe later` label should probably be renamed to `Priority: Low`.

### Actions needed

Once agreement has been reached on this, the following actions need to be taken:
- [x] Add the new labels and rename labels.
- [x] Where relevant, re-tag issues currently labeled with tags which will be removed. For the (closed) VIP related issues, these can be re-tagged to the ruleset a sniff is still currently in or the tag removed if the sniff will be removed.
- [x] Remove labels slated for removal.

If someone feels so inclined, going through the all (open) issues/PRs to verify labels would be a bonus as that just makes issues easier to find.
A good culling of open issues would also not be a bad thing :wink: 

And while we're at it: IMO, the `Awaiting feedback`, `Maybe later`, `PR exists` and `Review ready` labels should be removed from issues/PRs when they are being closed.
And if the `Investigation`/`Needs investigation` label would remain, that label should be removed from issues when they are closed as well.
 Comments: 
 Comment 0: > `Component: Upstream` - PHPCS upstream is not a component of this repo, so I'd like to propose renaming this label to `PHPCS: upstream`.

I'd suggest `Upstream: PHPCS`, since `Upstream` seems more like the category here.



> `Requirement: phpcs 3.x` should probably be changed to `Requirement: higher phpcs version` or `Requirement: dependency change` - as that way the same label can continue to be used, even when it would become phpcs 3.3.x or phpcs 4.x in the future or if more dependencies are added, it can be (re-)used for those too.

Other than in code comments, I don't think we have anywhere else centralised that keeps track of what compatibility code could be removed when the minimum PHPCS version is bumped (there may be some individual tickets, but that takes time to pull together). Instead of generalising, I think these comments could be copied into Issues at the time of the PR being merged, and the labels could be added/changed to `Requirement: PHPCS 3.0`, `Requirement: PHPCS 3.1`, `Requirement: PHPCS 3.2`, `Requirement: PHPCS 3.3`, `Requirement: PHP 5.4` etc.

> `Component: VIP Blocker` - as the VIP sniffs are slated for removal and the VIP CS checks are now contained in their own dedicated repo, this label is superfluous.
> `Component: VIP Caution` - same as above.

I think these could be consolidated into `Component: VIP`, but kept until the VIP sniffs have actually be removed. I started going through the remaining VIP-tagged tickets on our repo, to see if they were still valid for _someone_, and opened a few in the Automattic VIP CS repo. I'd like to get that task finished off before yanking the labels from those issues. Or I can open an Issue with a list of VIP-tagged tickets, to make them easier to find.

> Alternatively, the label could be renamed to `Status: Needs investigation` which would more clearly indicate that the issue is up for grabs.

+1

> `Type: Chores` if they don't already have that label. `Chores` covers more than just `Cleanup` which is why I think that's the better label to keep.

-0.5. Fixing a typo in an error message would be a cleanup, but I wouldn't count it as a chore.

I'm in favour of all the other suggestions.
 Comment 1: > I'd suggest `Upstream: PHPCS`, since Upstream seems more like the category here.

Yeah, I was struggling a bit with the name for this one, but calling it `Upstream: PHPCS` would sort it to the very bottom of the label list, while context -wise, it felt more logical to have it near the `Component` labels, which is why I proposed `PHPCS: upstream`.

If we can come up with an better name which would sort the label to still be above the `Status` and `Type` labels, that would be my preference.

> Other than in code comments, I don't think we have anywhere else centralised that keeps track of what compatibility code could be removed when the minimum PHPCS version is bumped (there may be some individual tickets, but that takes time to pull together). Instead of generalising, I think these comments could be copied into Issues at the time of the PR being merged, and the labels could be added/changed to Requirement: PHPCS 3.0, Requirement: PHPCS 3.1, Requirement: PHPCS 3.2, Requirement: PHPCS 3.3, Requirement: PHP 5.4 etc.

I'm not sure I fully understand what you mean here as that would either mean that we'd have a long list of `Requirement` labels with only one or two issues tagged with them or that older issues which have the `Requirement` label will be mislabeled if the label is re-used and re-named (which is currently the case).

> I think these comments could be copied into Issues at the time of the PR being merged

I normally mention these kind of things in the PR description as well, so I don't think that's the issue.

> Fixing a typo in an error message would be a cleanup, but I wouldn't count it as a chore.

`Type: Chores/cleanup` ?
 Comment 2: > I think these could be consolidated into Component: VIP, but kept until the VIP sniffs have actually be removed. 

As it's only going to be a few more months, I'd be happy to leave the `VIP` component labels in place until VIP has been completely removed.

Basically action 2 and 3 can be done on the go: once all issues for a label which should be removed have been relabeled, the label can be removed. For most labels this can be done quite quickly, for the `VIP` labels, it will just be a little longer.
 Comment 3: > I'd suggest `Upstream: PHPCS`, since Upstream seems more like the category here.

I was going to suggest the same thing. Is the sorting really that important?

Everything else sounds OK to me.
 Comment 4: > Is the sorting really that important?

For me, no, not once I know the labels on a project. Typing into the search box tends to be quicker to filter labels anyway.
 Comment 5: > > I think these comments could be copied into Issues at the time of the PR being merged
> 
> I normally mention these kind of things in the PR description as well, so I don't think that's the issue.

But the PR gets closed. My suggestion is that a new Issue be opened at the same time, as a reminder to do the removal once the minimum version of a requirement is met and tag it as such.

For instance:
- Remove workaround for PHPCS < 3.2.0 compatibility in `FileName` sniff and test (tagged: `Requirement: PHPCS 3.2`)
- Remove multiple PHPCS 2.x compatibility conditions in `PHPCSHelper.php` (tagged: `Requirement: PHPCS 3.0`)
- Remove PHPCS 2.x compatibility in `ArrayIndentationUnitTest.php` (tagged: `Requirement: PHPCS 3.0`)
- Remove PHPCS < 3.3 compatibility in `MultipleStatementAlignment` and `DisallowInlineTabs` sniffs and tests (tagged: `Requirement: PHPCS 3.3`)
- Remove PHPCS 2.9 compatibility in `PrecisionAlignment` sniff (tagged: `Requirement: PHPCS 3.0`)

etc.

Then, once we decide that, for instance, PHPCS 3.2 is going to be the minimum supported version, we can then tackle everything with requirement labels up to and including 3.2, and not have to also check to see if the requirement labels actually include stuff for 3.3 as well.

Does that make sense?

A quick check suggests that there's maybe only twice as many as I've listed above, so it wouldn't be a huge undertaking if they all had a `Status: Requirements not met` tag, to explain why they were on hold.
 Comment 6: @GaryJones I see what you mean. Except - until PHPCS 3.x was released that wasn't a problem. We just raised the minimum requirement. I remember we did this a number of times in the year before PHPCS 3.x was released.

It is only because of the dual 2.x/3.x support period that we are currently not doing so, as far as I'm concerned.
And I have been keeping track of a lot of the things we can change/fix/improve once we drop 2.x support (and raise the minimum PHPCS requirement to 3.x with the x still to be decided upon) in the ticket which is dedicated to that #1048.

I'm just concerned we'll end up with a very long list of outdated labels which have only been used for one (closed) ticket, which is why I proposed having a more generic name for the label.

If we are concerned about the version numbers being buried in the ticket - GH now offers the option to have [multiple issue/PR templates](https://blog.github.com/2018-01-25-multiple-issue-and-pull-request-templates/), so we could create one like this for those type of tickets:
```
<!-- Please mention the dependency name + new minimum requirement in the ticket title
For instance:
PHPCS 3.2+: drop work-around in Filename sniff
or
PHPCS 3.3+: add new sniffs which have become available
-->

Description of the feature which can be used/work-around which can be removed, once the minimum requirement has been raised.

Please also add links to the release notes and possibly the PHPCS upstream issue in which the feature was discussed.
```

If we do that, in combination with the `Status: Requirements not met` label you mention above, would that be sufficient ?
 Comment 7: FYI: I've created the `Auto-fix Core` project and added all the issues with the `Project: auto-fix WP Core / trac-41057` label to it.

Once the `Component: Core` label has been added, we can re-tag all those issues with that label and remove the `Project` label.
 Comment 8: > If we do that, in combination with the Status: Requirements not met label you mention above, would that be sufficient ?

As long as they are easy to find (and your approach sounds like it would be - filter on the tag, and then look through ticket titles), that works for me.
 Comment 9: So, to conclude:

### Add labels
* `Component: Core`
* `Repo: meta`
* `Status: help wanted`
* `Status: good first issue`
* `Priority: High`

### Rename labels
* `Component: Upstream` => `Upstream: PHPCS`.
* `Requirement: phpcs 3.x` => `Status: Requirements not met`
* `Maybe later` => `Priority: Low`
* `Status: Investigation` => `Status: Needs investigation`
* `Type: Chores` => `Type: Chores/Cleanup`

### Remove labels
* `Component: Templates`
* `Project: auto-fix WP Core / trac-41057 `
* `Status: PR Required`
* `Type: Cleanup `

### Remove labels once WPCS 2.0 has been released
* `Component: VIP Blocker`
* `Component: VIP Caution`

### Actions needed now
- [x] Create `Auto-fix WP Core` project and add all issues labeled with the old tag to it.
- [x] Add the new labels and rename labels.
- [x] Create issue/PR template(s) - @GaryJones is this something you would like to tackle ?
- [x] Where relevant, re-tag issues currently labeled with tags which will be removed.
- [x] Remove redundant - `Awaiting feedback`, `PR exists`, `Review ready` and `Needs investigation` - labels from closed issues/PRs.
- [x] Remove labels slated for removal (round 1).

### Actions needed later
- [x] Go through and close or re-tag the VIP issues.
- [x] Once WPCS 2.0..0 has been released, remove the VIP labels (round 2).

### Bonus actions
- [x] Go through current `Status: Requirements not met` issues and update the issue title if needed.
- [x] Open issues for various `Status: Requirements not met` enhancements.
- [x] Going through the all (open) issues/PRs to verify and update the labels.
- [x] Close outdated issues.

Everyone agreed ?

Please claim and execute actions listed here freely ;-)
 Comment 10: > Repo: meta

Entered as `Meta: Repo`, and also added a `Meta: Packagist` as well.

> Component: VIP Blocker
> Component: VIP Caution

Consolidated into `Component: VIP`.

Idea: Since the `Component` category is now `Core`, `Docs`, `Extras` and `VIP`, should the category be more explicitly called `Ruleset`?

I renamed the `Type: Modern PHP`, to be `Focus: Modern PHP` since the Focus category name is more accurate here.

Aside: I recently [helped](https://github.com/pods-framework/pods/issues/5016) Pods update their [labels](https://github.com/pods-framework/pods/labels) - they have a lot more, with categories of `Focus` and `Keyword`, and `Closed` (resolution) category, as well as the usual categories that we have here. Posting in case it adds inspiration.

> Remove redundant - Awaiting feedback, PR exists, Review ready and Needs investigation - labels from closed issues/PRs.

All done, other than [this one](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues?utf8=%E2%9C%93&q=label%3A%22Status%3A+Awaiting+Feedback%22+sort%3Aupdated-desc+is%3Aclosed+), which makes me think we should have `Closed: No feedback` tag, which helps distinguish it from open issues awaiting feedback (or just not bother with removing Awaiting Feedback from closed issues/prs).
 Comment 11: @GaryJones Thank you for taking on a lot of these actions.

Is is just me or have a lot of labels new colours ? Sorry, it's confusing me a bit and I'm not so sure about some of the colours - like bright red for `High Priority`, which feels a bit over the top, quite apart from it being the same colour used for bugs.

> Entered as Meta: Repo, and also added a Meta: Packagist as well.

What is the `Meta: Packagist` label for ? And why does this need a separate label ?

> Aside: I recently helped Pods update their labels - they have a lot more, with categories of Focus and Keyword, and Closed (resolution) category, as well as the usual categories that we have here. Posting in case it adds inspiration.

I opened this issue more with an eye on having *less* labels, rather than more and having those labels be atomic.
Let's also not confuse labels, with projects or ticket statuses. Why have a label category `Closed` when you can just close the issue ?

> (or just not bother with removing Awaiting Feedback from closed issues/prs).

That makes sense to me, Or:
* Remove it if feedback was received and enough to close the issue and
* Leave the tag if no feedback was received and the issue was closed for lack or response.
 Comment 12: Is it just me or have the `Project: auto-fix WP Core / trac-41057` issues not be retagged to `Component: Core` ?
 Comment 13: > Is it just me or have the Project: auto-fix WP Core / trac-41057 issues not be retagged to Component: Core ?

There only seemed to be two open, which I re-tagged, but then I deleted the old label before realising the closed issues needing re-tagging as well 😨 

I was going to go through the Done Issues in the Project and manually tag them all as `Component: Core`.
 Comment 14: > Is is just me or have a lot of labels new colours ? Sorry, it's confusing me a bit and I'm not so sure about some of the colours - like bright red for High Priority, which feels a bit over the top, quite apart from it being the same colour used for bugs.

Most of the colours stayed the same, though new labels are somewhat random - I tried to keep them somewhat distinct, but I've no objection to any of them being changed.

The high priority one was intentionally meant to draw visual attention, but again, feel free to change. I'm not tied to any of the colours.

> What is the Meta: Packagist label for ? And why does this need a separate label ?

We have had a [few mentions of Packagist](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues?utf8=%E2%9C%93&q=Packagist), though only one appears to be worthy of tagging. I added it because it made sense to me. If someone sees that label here, they might feel more confident in reporting / asking about a Packagist + WPCS related issue.


> I opened this issue more with an eye on having less labels, rather than more and having those labels be atomic.

I think the number of labels at Pods is too many, but I think we can still be atomic with more labels here.

> Let's also not confuse labels, with projects or ticket statuses. Why have a label category Closed when you can just close the issue? 

Tickets can be closed, but that doesn't say why. Invalid? Duplicate? No feedback? Implemented? Rejected? Labels allow a much finer-grained filtering and instant understanding, without having to actually read through the (end of the) Issue.
 Comment 15: > I was going to go through the Done Issues in the Project and manually tag them all as Component: Core.

Already done now ;-)
 Comment 16: > Already done now ;-)

Just saw - thank you! I started earlier but hadn't found a way to bulk edit issues in a column.

Other label-tidying tasks:

 - [x] [Unmerged closed PRs with a milestone](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/pulls?utf8=%E2%9C%93&q=milestone%3A*+is%3Aclosed+is%3Aunmerged+sort%3Aupdated+) - remove milestone
 - [x] [Merged PRs with no milestone](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/pulls?utf8=%E2%9C%93&q=no%3Amilestone+is%3Amerged+sort%3Aupdated) - set milestone
 - [ ] [Issues/PRs with no labels](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues?utf8=%E2%9C%93&q=no%3Alabel) - add label(s)

 Comment 17: > I started earlier but hadn't found a way to bulk edit issues in a column.

Nope, can't find that either, not even a quick label option. Though you can click on the issue, get an issue summary pop-up and add the labels from there. Still no fun to do ;-)
 Comment 18: Re: label colours - I'll have a quick think about it and have a go at it, we can just iterate based on trial and error for those.

> We have had a few mentions of Packagist, though only one appears to be worthy of tagging. I added it because it made sense to me. If someone sees that label here, they might feel more confident in reporting / asking about a Packagist + WPCS related issue.

Looking through those issues, there are only two - #654, #1393 -, maybe four - #195, #855 - which I think qualify for `Meta` status and those could just as easily be tagged with `Meta: repo` IMO.
Alternatively, maybe we should rename the `Meta: Packagist` label to `Meta: outside integrations` ? Then it could cover principle decisions about things related to Composer, Packagist, PHPStorm etc.

The rest look to be end-user questions which should be tagged as `Question`.

> Tickets can be closed, but that doesn't say why. Invalid? Duplicate? No feedback? Implemented? Rejected? Labels allow a much finer-grained filtering and instant understanding, without having to actually read through the (end of the) Issue.

Don't we already do that though ? We use the `Invalid`, `Duplicate`, `Wont fix` labels for that, don't we ? And those can also be used when the issue is still open, for instance, when the initial issue assessment is `Invalid`, but the issue is left open (briefly) with a question to confirm that the issue has been understood correctly.

`Rejected` and `Won't fix` seem too closely related to be separate labels, though I can get behind renaming `Won't fix` to `Rejected`.

> Unmerged closed PRs with a milestone - remove milestone

Well, in those cases, the milestone communicates for which release the PR was considered, which could be considered valuable information.

>  Merged PRs with no milestone - set milestone

:+1: Though I suspect that will only be really old stuff as for the last few years, we've been good about this.
 Comment 19: > Merged PRs with no milestone

Just gone through the first page & added milestones, but I'm now running into the fact that we haven't actually got milestones for the really old releases ( < 0.4.0) :joy: 
 Comment 20: > Unmerged closed PRs with a milestone - remove milestone

I went ahead and removed these - I don't think it serves any purpose (and it's what happens on Core Trac as well).

> Merged PRs with no milestone - set milestone

I added new milestones, set the due date as the actual release date, went through and added all the PRs, and then closed the milestones.
 Comment 21: In terms of the dependency change reminders, I wonder if there's more benefit in having a single Issue for each dependency version, that can be updated with more checkboxes as needed?

#xxxx Dependency Change Reminders: PHPCS 3.0
#xxxy Dependency Change Reminders: PHPCS 3.1
#xxxz Dependency Change Reminders: PHPCS 3.2

There can still be multiple PRs that reference the same Issue as we come to implement the changes.
 Comment 22: @GaryJones Absolutely. Sounds like a good idea for the future.

For PHPCS 3.0.0 to current, I've dropped most of the interesting titbits in issue #1048 (Drop PHPCS 2.x support). Based on everything there I would advocate for the next minimum supported version to be at least PHPCS 3.3.0.
When I'm ready to start creating the PR for that issue, I'll open a separate issue with a summary of the reasons for that to see if there's consensus about that and prepare the PR based on the response.
Once that PR has been merged, we can see what's left over and open separate issues for the other PHPCS versions.

Only problem I can see is that sometimes, a PR might be open in PHPCS which is interesting enough to open an issue about it here, but that it is unclear in which PHPCS version it will be merged.

Think the recent issue about detecting merge conflict artifacts left in code #1432. We could open a reminder issue to say that once the upstream PR has been merged and we'd raise the minimum supported PHPCS version, we should add that sniff, but the PR has been open for ten months so far, so it is unclear when it will be merged.
 Comment 23: > Only problem I can see is that sometimes, a PR might be open in PHPCS which is interesting enough to open an issue about it here, but that it is unclear in which PHPCS version it will be merged.

That's fine - we can update the PR title, or move the checkbox item between Issues / open a new issue etc.
 Comment 24: @GaryJones As VIP has been removed by now, did you still want to go through & relabel what's under that label now ?

Other than that, the label should probably be removed and this issue closed. Or are there still other outstanding actions ?
 Comment 25: > As VIP has been removed by now, did you still want to go through & relabel what's under that label now ?

Yes - thanks for the reminder.

Convenience link: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues?q=label%3A%22Component%3A+VIP%22+is%3Aopen+sort%3Aupdated-desc

cc @rebeccahum 	
 Comment 26: @jrfnl I've made a note of the issues in https://github.com/Automattic/VIP-Coding-Standards/issues/390, so they can all be closed (if they no longer apply), and have their label removed.
 Comment 27: I've now closed (or left open) the 10 issues as seemed suitable. I've removed the label from each, and now deleted the label completely.
 Comment 28: Thanks @GaryJones !

I've just re-read this whole thread (it's long!) and the only remaining action item IMO is:

- [ ]  Go through the [list of issues/PRs without any label](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) and tag them
 Comment 29: FYI: I've done another round of culling issues and adding labels to them. Still quite some to go, though mostly `closed` issues.

I've also added three more `Focus: ...` labels to help find related issues more easily:  (after the `Focus: Security` label was added a little while back)
* `Focus: I18n`
* `Focus: Code Analysis`: Sniffs to prevent common mistakes and improve code in general.
    Most of these issues would require new sniffs and some could be considered for pulling to PHPCS itself.
* `Focus: WP interoperability`: Doing things the WP way, prefer using WP functionality over userland/PHP native 


{'source': 'GithubIssues', 'repo_name_with_owner': 'WordPress/WordPress-Coding-Standards', 'issue_id': 351464344, 'repo_stars': 2188.0}