memory performance: two-level cmap lookup

[lsf37]

This addresses the memory issue #199. With more recent Unicode versions, the
character map took 0x110000 * 4 bytes, i.e. ~4MB. Most of this is never
accessed, but it still increases overall memory consumption esp for multiple
scanners.

This PR:

• changes the current one-level array to a two-level table structure
• adds quickcheck tests for the table construction
• updates runtime engine to use that structure
• updates skeleton files to remove reference to old ZZ_CMAP
• removes trailing white space in generated template code

Typical memory consumption for the char map decreases from ~4MB to < 100KB,
for simple scanners (little unicode use > 0xFF) to ~20KB.

Even though this increases the number of operations in the innermost loop,
with a bit of luck performance might actually benefit because of better
cache locality. Benchmarking still to be done.

[lsf37]

This solution is similar to, but (hopefully) simpler than the one implemented for the IntelliJ plugins in #199, with similar memory improvements.

It does not really address the ArrayIndexOutOfBounds problem, but this has already disappeared with @sarowe's work on more recent Unicode versions. For %unicode 2.0, you will still get an exception for code points >= 0xFFFF, but that is as it should be, because that Unicode version doesn't have these characters. The later versions (including the default just %unicode) that do have higher code points don't throw the exception. This is similar to %7bit and %8bit scanners throwing the same exception for higher characters.

There is the question whether this is the best behaviour, i.e. one could throw a different exception or report a more user-friendly error, but that is a separate question.

[lsf37]

The trailing whitespace removal is a bit out of place here -- it slipped in because my editor is set to stripping whitespace, which I forgot about. I think it's nicer to have them removed, though, so I left it.

[lsf37]

ps: huge kudos to @sarowe for the excellent unicode test suite coverage. This and the new quickcheck setup helped a lot in getting that feature implemented much faster than usual.

[lsf37]

Will merge this one now, because I have too many things stacking up, but am still interested in feedback if there is time.