Teach regex optimizer to handle above-Latin1

Teach regex optimizer to handle above-Latin1

Until this commit, the regular expression optimizer has essentially
punted on above-Latin1 code points.  Under some circumstances, they
would be taken into account, more or less, but often, the generated
synthetic start class would end up matching all above-Latin1 code
points.  With the advent of inversion lists, it becomes feasible to
actually fully handle such code points, as inversion lists are a
convenient way to express arbitrary lists of code points and take their
union, intersection, etc.  This commit changes the optimizer to use
inversion lists for operating on the code points the synthetic start
class can match.

I don't much understand the overall operation of the optimizer.  I'm
told that previous porters found that perturbing it caused unexpected
behaviors.  I had promised to get this change in 5.18, but didn't.  I'm
trying to get it in early enough into the 5.20 preliminary series that
any problems will surface before 5.20 ships.

This commit doesn't change the macro level logic, but does significantly
change various micro level things.  Thus the 'and' and 'or' subroutines
have been rewritten to use inversion lists.  I'm pretty confident that
they do what their names suggest.  I re-derived the equations for what
these operations should do, getting the same results in some cases, but
extending others where the previous code mostly punted.  The derivations
are given in comments in the respective routines.

Some of the code is greatly simplified, as it no longer has to treat
above-Latin1 specially.

It is now feasible for /i matching of above-Latin1 code points to know
explicitly the folds that should be in the synthetic start class.  But
more prepatory work needs to be done before putting that into place.
...