Make the space in error comments optional

[wyattscarpenter]

Make the spaces in test error comments optional and more flexible, so instead of # E: whatever you can now write #E :whatever (for example). This will prevent people from erroneously entering error lines which are then ignored. Fixes #19547.

I have written tests for this feature, but have not affirmatively documented it, because I don't want to encourage irregularity in the error comments people write.

Amusingly, this seems to have uncovered several problems with the expected values in some test cases, which I have also fixed. These fixes fell into 3 categories:

• accidental duplication of an # E: or an # N:
• accidentally used a type ignore after an E (you can tell it's an accident in this case because it type-ignores the very error the E is looking for), which wouldn't have worked in any case because of type: ignore command not recognized after other comment #19366
• used python comments (#) instead of test comments (--) for disabling a line with an # E :, so now that that syntax with the interstitial space is valid the E triggers. I turned this one into an xfail instead, based on what it was doing.

[wyattscarpenter]

Ah, there are a lot of urls with fragments in there. Hmm.

Maybe the whole parser should be changed and simplified...

Or perhaps just match space and beginning of line.

[wyattscarpenter]

Why the heck am I still getting test failures like

 Alignment of first line difference:
  E: tmp/foo.pyi:23: note: def f(self, x: int) -> int
  A: tmp/foo.pyi:23: note:     def f(self, x: int) -> int

[wyattscarpenter]

I added a .strip to it... it's then constructed with a template string... what the hell...

[edit: commit with .strip not pictured in current branch history]

[wyattscarpenter]

Oh...

[wyattscarpenter]

Amusingly, this seems to have uncovered several problems with the expected values in some test cases, which I will now fix...

[wyattscarpenter]

This split regex is too complicated, and a new one should be made based on #21172. (we can rebase/cherry-pick this whole PR onto the new master once that's accepted) The documentation should also, I guess, be updated according to the actual rules, which will involve \s probably. I'm very skeptical of the \S I added below, but I can think that through later.