Support @supports {rule} in mapcss

[Famlam]

Adds basic support for @supports {} blocks in mapcss

It doesn't really parse the @supports conditions, that would be:

1. Unnecessary difficult :)
2. Give dilemma's, e.g. we try to mimic JOSM's parsing, so should we return true or false on user-agent: josm?

Instead, it checks if there is a -osmoseItemClassLevel property present, and only if so, it assumes it's safe for Osmose. All other (possibly unsafe) rules are discarded.

Note that the regeneration of mapcss didn't add new rules to transport.validator.mapcss because last time the rule that is now in @supports was already present; it was just not in a @supports context. (See this old-new comparison)

Note on the changes in the *.g4 file: the whitespace after the SUPPORTS_NOT must be present. If not, antlrs generated file will detect the not in i.e. *[not:name][name]["not:name"=*"name"], from plugins/notprefix.validator.mapcss as such a SUPPORTS_NOT, failing to compile after that. (This also happens with set, but as we don't have rules with *[set* it doesn't cause issues). If you want to avoid this, we have to move these fixed string rules (SUPPORTS_NOT, SUPPORTS_AND, SUPPORTS_OR, and SET) to the end of the g4 file (although I didn't check yet if this causes other issues for set).

See #2077

[frodrigo]

Ok. Thank you.