Only tag, value, and global-ness of features are considered, not their
start/end offsets.

Such that we don't accidentally use info not in the cache key.

And include it in hb_shape_plan_t itself.

This is the root cause of bug worked around in 19e77e01.

Still no shape plan caching for variations though.

No other shaper will need shape_plan_data, by definition.  So, remove
abstraction layer and always create hb_ot_shape_plan_t as part of
hb_shape_plan_t.

To remove custom null object next..

More useful.

Show up with gcc -O0.

There's a few more but those are functions that need to be filled in.

Maybe this is a lost battle...

Sorry for the noise, downstream custom builders.  Please adjust.

Found and fixed a couple bugs.

Found a couple multithreading issues.  Marked them with "XXX-MT-bug".

Finally, unified!

Part of fixing https://github.com/behdad/harfbuzz/pull/605

This is a temporary hack just to avoid incorrect shaping results, pending proper support
for caching shape-plans with variation coordinates.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1452#c5

CC https://github.com/behdad/harfbuzz/issues/139

clang's new -Wcomma compiler option warns about possible misuse of the
comma operator such as between two statements.

hb-common.cc:190:9 [-Wcomma] possible misuse of comma operator here
hb-ot-layout-gsubgpos-private.hh:345:30 [-Wcomma] possible misuse of
comma operator here
hb-shape-plan.cc:438:26 [-Wcomma] possible misuse of comma operator here

Shape-plan caching is not implemented.

Move the empty-buffer check from hb_shape_full() to hb_shape_plan_execute().

Reported by Simon Cozens.

Based on data from http://upstream-tracker.org/versions/harfbuzz.html
Resolves #103