In preparation to move add per-subtable set digests...

Oops.  Was checking for kern feature in GSUB, not GPOS.

Hopefully more clear.

Previously we only did if there was no GPOS whatsoever.  This applies
to Arial, Times New Roman, etc in Win7.  Was not kerning before.  It
is now.

For 329f2401

max_ops is signed.

Since we consume it legitimately during shaping.

Still, not hooked.

Not hooked up to be called yet.

Makes our FT-backed hb_font_t safe to use from multiple threads.  Still,
the underlying FT_Face should NOT be used from other threads by client
or other libraries.

Maybe I add a lock()/unlock() public API ala PangoFT2 and cairo-ft.
Maybe not.

**Finally**!  Casual users can stop caring about font-funcs completely now,
like they haven't been needing to care re unicode-funcs for a few years.

Now that we have get_h_advances() and get_nominal_glyphs() implemented, the
overhead of doing a proper atomic load would be once per run, NOT once per
glyph.  So, no need to pre-load the tables to avoid that overhead.

As such, hb_ot_font_set_funcs() has become really cheap.  Can *finally* make
it be default font functions on all newly created fonts!

Some more measurable speedup.  The recent commits' speedups are as follows:

Testing with Roboto, ****when disabling kern and liga****:

Before:

FT --features=-kern,-liga
user↦   0m0.521s

OT --features=-liga,-kern
user↦   0m0.568s

After:

FT --features=-liga,-kern
user↦   0m0.428s

OT --features=-liga,-kern
user↦   0m0.470s

So, 17% speedup.

Note that FT callbacks are faster than OT these days since we added an advance
cache to FT.  I don't think the difference is enough to justify adding a cache
to OT.

When not disabling kern, the thing is three times slower, so the speedups
are three times less impressive...  Still, 5% not bad for a codebase that I
otherwise thought is optimized out.

Note that, because of this and other optimiztions in our main shaper,
disabling kern and liga, the OT shaper is now *faster* than the fallback
shaper.  So, that's my recommendation to clients that need the absolute
fastest...

Even without FT or OT font funcs implementing get_nominal_glyphs(), there's measurable
speedup.

Even has measurable speedup...

Towards separating the common case into its own loop.

Unused as of now.  To be wired up to normalizer, which would remove
overhead and allow hb-ot-font initialization to become a no-op, so
we can enable it by default.

Instead of passing a CFLAG/CXXFLAG to define HB_EXTERN, define it
directly in src/hb.hh as __declspec(dllexport) extern when we are
building HarfBuzz as DLLs on Visual Studio.  Define HB_INTERNAL
as nothing without defining HB_NO_VISIBILITY when building HarfBuzz as
DLLs to avoid linker errors on Visual Studio builds.

Also "install" harfbuzz-subset.dll into $(PREFIX)\bin as the
hb-subset utility will depend on that DLL at runtime, when HarfBuzz is
built as DLLs.  Since it consists of private APIs that are subject to
change, we do not install its headers nor .lib file.