feat(td-ref-attr): report headers attribute referencing other <td> elements as unsupported

[engineerklimov]

Fix for the header attribute check. The check will report cells that references other <td> elements. Added unit and integrations tests as requested in corresponding issue.

Closes: #3987

[engineerklimov]

Please, let me know if there are any changes needed. Thanks!
@WilcoFiers and @straker for vis.

[WilcoFiers]

@engineerklimov Heyya, apologies about the delays. Lots to do. I'll try to get to it within the week.

[engineerklimov]

Appreciate your response, Sir
Looking forward to the review

[WilcoFiers]

There are some scenarios the original ticket didn't consider that I feel we need to test before we can start failing this. Let me know if you have the necessary software to do this testing, otherwise we'll see what we can do on our end. At the very least we'll need to test this with NVDA + Firefox and JAWS + Chrome. Normally we'd also want VO + Safari but since it doesn't support the headers attribute anyway there's no point in that.

[WilcoFiers]

I'm going to change this PR title to "feat". This PR makes the rule stricter, we can't put that in a patch release.

[engineerklimov]

@WilcoFiers I did all changes, the only thing left is locales updates. Can you check error messages? If they are fine i will update all translations.

[WilcoFiers]

LGTM. Let me ask a colleague for a final OK, since I wrote part of the solve.

[dbjorge]

Thanks for the contribution! This is looking good overall, just noticed a few more bits to clean up

[engineerklimov]

I tried to update locales. I found that all locales are quite outdated. Not sure that this change is good place to bring all locales up to date. So i updated only "ru" which i contributed recently. Not sure what is contribution policy here.

[dbjorge]

I appreciate the attempt to make this more concrete for folks that might not know exactly what a "header cell" formally means. But for consistency with other rules, it's actually preferable for "help" to be the shorter one rather than "description" (the fields are poorly named; "help" is really more like "suggested tooltip", so we try to keep it more concise than this). For both of them, we try to keep the overall lengths consistent between rules and fairly concise; the old help text was already towards the wordier end of what we prefer. When I'm trying to decide on wording for these, I find it helps to dump all the properties for each rule alongside one another with jq .metadata.description lib/rules/*.json and jq .metadata.help lib/rules/*.json.

But I do agree that it's more understandable to use precise element/attribute names. I think we can actually get away with not mentioning the "role=" option in the text here; we only allow headers to point to a non-<th> element with header roles because it happens to be accessibility supported (ie, not a WCAG violation), but it's not actually compliant with the HTML standard (which requires pointing specifically to <th> elements), so I don't think we need the help text to encourage it as an option. In general, rule descriptions/help can and should omit mention of edge cases that we don't encourage but technically allow.

Suggested change

	"description": "Ensure that each cell in a table using the headers attribute refers only to header cells within that table",
	"help": "Table cells using the headers attribute must refer only to header cells or data cells with the role=columnheader/rowheader within the same table."
	"description": "Ensure that each cell in a table that uses the headers attribute refers only to other <th> elements in that table",
	"help": "Table cell headers attributes must refer to other <th> elements in the same table."