Prevent additional @legacy-covers annotation from being added to test methods

Not sure this worth doing, why would we add new instances of this annotation now the conversion is done?

Okay, let's try to do it - but what should we do about the existing instances? Should we just delete them if they are meaningless?

I've just re-read the discussions on GitHub and it's somewhat annoying that multiple people have requested CoversMethod to be allowed on test methods but PHPUnit have decided that this is not necessary, without any real explanation other than "it's not needed". They seem to imply that #8.4 is the way forward but there's no way we can implement that in Drupal given the size of the existing test suite. But if they are insistent on not adding the feature then I am not entirely sure of the point of keeping this metadata in the codebase, because we won't be using it for anything either.

I think that we could remove @legacy-covers in cases where the test method name starts with the covered method, e.g. in OverridesSectionStorageTest:

 * @legacy-covers ::getContexts
 */
public function testGetContexts(): void {
...
 * @legacy-covers ::getContextsDuringPreview
 */
public function testGetContextsDuringPreview(): void {
...
 * @legacy-covers ::getDefaultSectionStorage
 */
public function testGetDefaultSectionStorage(): void {
...
 * @legacy-covers ::getTempstoreKey
 */
public function testGetTempstoreKey(): void {

or BlockComponentRenderArrayTest:

 * @legacy-covers ::onBuildRender
 */
public function testOnBuildRenderInPreviewEmptyBuild(): void {

 * @legacy-covers ::onBuildRender
 */
public function testOnBuildRenderEmptyBuild(): void {

 * @legacy-covers ::onBuildRender
 */
public function testOnBuildRenderEmptyBuildWithCacheTags(): void {

To me this isn't adding much value.

Hoisting them all to the class level also seems pointless when our test classes are often 1:1 with the classes under test - I think you will end up with a list of all/most public methods in the class, which again doesn't add value. But in cases where this isn't true, perhaps there is value in hoisting them to the top level - not sure how many cases we will have of that though.

Agree putting the blocker would be nice

Sorry I don't think we should baseline this unless we know what we're going to do about them, for a start it means there's no way to remove them from the baseline consistently.

I've committed MRs with @legacy-covers recently because that's what we used for existing annotations in core when we updated, on the basis that we would convert them from @legacy-covers to something else later but that the information would be preserved in the meantime.

If we're just going to delete them, we should do that, and then add the phpstan rule. If we're going to do something else, we should figure out what that thing is going to be first.

If we think this information is valuable but we want to get rid of these annotations, there is nothing stopping us adding CoversMethod in our own namespace (or even stealing PHPUnit's namespace, but that feels very wrong). Then if we do more with the coverage metadata in the future then we can read the annotation ourselves if needed, or if PHPUnit have a change of heart then we just have to swap back to their namespace. I am still on the fence as to whether this is useful at all in many cases, though.