Rascal layout does not match current Unicode whitespace specification

[toinehartman]

Describe the bug

The Rascal grammar rule for layout contains many different white-space characters, with the aim to follow the Unicode specification.

rascal/src/org/rascalmpl/library/lang/rascal/syntax/Rascal.rsc

Lines 531 to 535 in f4fb042

	lexical LAYOUT
	= Comment
	// all the white space chars defined in Unicode 6.0
	| [\u0009-\u000D \u0020 \u0085 \u00A0 \u1680 \u180E \u2000-\u200A \u2028 \u2029 \u202F \u205F \u3000]
	;

At the time of writing, it followed Unicode 6.0. However, since 6.3, the 'Mongolian vowel separator' (\u180E) is not considered white-space anymore.

We should consider removing this from the grammar to better align with Unicode.

Downside If anyone felt the urgent need to use this character as layout in their Rascal module, they will get (hard-to-debug) parse errors.

Desktop (please complete the following information):

• Context: Eclipse plugin, Commandline REPL
• Rascal Version: 0.41.3-RC8

Additional context
https://unicode-explorer.com/c/180E

[jurgenvinju]

Unicode... <sigh>. Maybe we should go back to plain ASCII for this definition. How does it help anybody we accept these hard to debug characters.. I'm ok with these characters in string constants, where they make sense, but in our own whitespace. I think we over-generalized a bit too much.

[DavyLandman]

This was added (in 2012) when we figured out that:

1. not all keyboards generate 0x20 for spaces (I think there was a Finish user many years back that first encountered this)
2. having a parse error on a whitespace is very hard for a user. I distinctly remember a debugging session with @PaulKlint looking at the file and why it was showing parse errors on a space.

I think we should indeed drop the \u180E but not drop all the others. If only for not introducing breaking changes.