Solve the static NAMED_PATTERNS (map) init

[xparq]

UPDATE: init() is now called implicitly when creating the first ATOM rule!
(And still also in Parser(), as a backup, to also support OP-only rules, and, well, just in case...)

Old memo from the source, just FTR:

It's currently done by the Parser ctor (because at least that has only one...), but RULE objects also need it: they can't even be created
before having that done... So, it's completely futile in Parser(...), as its syntax argument would get setup from a bunch of temporaries
created before the constructor's body had a chance to run...

Now, it could perhaps still be done in its first member init (e.g. to set some dummy initialized member), but this is too much cryptic
trickery just to fight C++ for little benefit. Just document that init() must be called for now...

Also, RULE has a whole bunch of ctors, so where to put it there?... :-/

(Note: the OP (handler) map looks like another shared object, but it's static only to make it a singleton, not for sharing. That one at least is only actually used by Parser!)

An invariant here is extensibility: currently the pattern names (IDs) are just strings, so that the building blocks (atoms) of grammars can be extended by users seamlessly, either by adding to or changing the NAMED_PATTERNS[] map, or by using string literals that can themselves be regex patterns (not just plain strings).

This really is shared data across all the RULE and Parser objects etc., and it can't be a const object either.

(I don't really want to even put its interface into Parser (or RULE), as it would feel less generic (like RULE::PATTERNS or Parser::PATTERNS), and that alone wouldn't solve the static init fiasco anwyay.)