Adds new lint rule to detect test overlap in web feature files

[ChrisC]

Adds a new OVERLAPPING-WEB-FEATURES-FILE lint rule that detects when the same test file is mapped to multiple features within a single WEB_FEATURES.yml file. (Overlap detection is file-based, not pattern-based: patterns are resolved to actual filenames first, so intentional exclusion patterns do not accidentally trigger the error.)

Error message design

Errors are grouped one per overlapping feature pair rather than one per overlapping file. This keeps output manageable in cases where many files are shared between two features. The message lists up to the first 5 overlapping filenames, followed by "and N more" for larger overlaps. Example:

OVERLAPPING-WEB-FEATURES-FILE: Features 'view-transitions' and 'view-transition-class'
share 17 overlapping test files: class-specificity.html, pseudo-with-classes-entry.html,
pseudo-with-classes-exit.html, pseudo-with-classes-match-ident.html,
pseudo-with-classes-match-multiple-wildcard.html, and 12 more

Silencing intentional overlaps

Authors who intentionally map the same test to multiple features (e.g. a test of two closely related features) can suppress this error using the existing lint.ignore mechanism:

OVERLAPPING-WEB-FEATURES-FILE: path/to/WEB_FEATURES.yml

(One downside of this approach is that it will be hard to selectively ignore specific overlaps within a single WEB_FEATURE.yml. It's possible that some future updates to the WEB_FEATURES.yml schema could more expressively address situations where overlap is intended.)

Existing overlaps

Currently, there are 57 WEB_FEATURES.yml files in the repo that already have overlapping mappings. For simplicity, I'm just assuming those are all intentional for now, and have added them to lint.ignore. So this PR introduces no new lint failures. Happy to revisit this added IGNORE list either in this PR or in a follow-up PR.

[foolip]

57 files with existing overlap seems like a lot, and needing to suppress a lint in so many cases suggests it will need to be suppressed regularly. What kind of overlap is the most typical here, is it when two features have explicitly listed the same file, when wildcards overlap with explicit file names, or overlapping wildcards? I'm wondering if the lint could be limited to avoid the most common scenario here.

[jcscottiii]

I think we should address the exclusion schema in RFC 237 first. If we have a fine-grained exclusion schema (like exclude_ids: at the rule level), we don't have to use lint.ignore for the entire file. Using lint.ignore creates a permanent blind spot in that file where future, unintentional overlaps can slip through (bit rot). If we fix it in the schema, the linter can stay active and protect the rest of the file from bit rot.

[ChrisC]

... Using lint.ignore creates a permanent blind spot in that file where future, unintentional overlaps can slip through (bit rot)...

Yeah, I think I agree that waiting on the resolution of the mentioned RFC is the most prudent move here for this reason.

But to answer @foolip's earlier question, the overwhelming majority of overlaps have to do with some combo of wildcard or recursive (**) pattern overlapping with other wildcard patterns or explicit filenames. The majority within this group (~43%) seems to be about some wildcard overlapping with another wildcard (eg. background-* overlapping with background-image-*).

Only 3 cases are explicit filename collisions:

1. text-indent/WEB_FEATURES.yml — text-indent-each-line and text-indent-hanging both explicitly list text-indent-each-line-hanging.html since the test covers both features equally.

2. selectors/parsing/WEB_FEATURES.yml — slot and shadow-parts both explicitly list parse-slotted.html. The test is relevant to both ::slotted (slot) and ::part (shadow-parts).

3. phrasing-content-0/WEB_FEATURES.yml — b and strong both explicitly list b-strong-styles.html, which verifies both elements' rendering.

These all do some to be pretty intentional and should be added to lint.ignore if a linter rule were added to prevent explicit filename overlap, but we would still have the future blind spot problem for later, unintentional collisions as @jcscottiii mentioned.