Move Unicode property defn processing to compile time

Move Unicode property defn processing to compile time

This patch moves the processing of most Unicode property definitions
from execution (regexec.c) to compilation (regcomp.c).  There is a cost
to do this.  By deferring it to execution, it may be that the affected
path will never be taken, and hence the work won't have to be done;
whereas, it's always done if it gets done at compilation.

However, doing it at compilation, has many advantages.  We can't
optimize what we don't know about, so this allows for better
optimization, as well as feature enhancements, such as set
manipulations, restricting matches to certain scripts, etc.  A big one,
about to be committed allows for significantly reducing the number of
copies of the data structure used for each property.  (Currently, every
mention in every regular expression of a given property will generate a
new instance of its hash, and so results of look-ups of code points in
one instance aren't automatically known to other instances, so the code
point has to be looked-up again.)

This commit leaves the processing to execution time when the class is to
be inverted.  This was done purely to make the commit smaller, and will
be removed in a future commit; hence the redundant test here will be
removed shortly.

It also has to leave to execution time processing of properties whose
definition is not known yet.  That can happen when the property is
user-defined.  We call _core_swash_init(), and if it fails, we assume
that it's because it's such a property, and if it turns out that it was
an unknown property, we leave to execution time the raising of a warning
for it, just as before.

Currently, the processing of properties in inverted character classes is
also left to execution time.  This restriction will be lifted in a
future commit, and this patch assumes that, and doesn't indent some code
that it otherwise would, in anticipation of the surrounding 'if' tests
being removed.