Unbreak build on Windows CE

0475ef2f broke the build by using
vsnprintf(), which is not defined on Windows CE

Improve DirectWrite backend

Ouch.  Had broken it in 9a13ed45

Fixes https://github.com/behdad/harfbuzz/issues/238
Will add test soon.

Actually copyedited same logic from Uniscribe to make it just work

Previously we only synthesized GDEF glyph classes if the glyphClassDef
array in GDEF was null.  This worked well enough, and is indeed what
OpenType requires: "If the font does not include a GlyphClassDef table,
the client must define and maintain this information when using the
GSUB and GPOS tables."  That sentence does not quite make sense since
one needs Unicode properties as well, but is close enough.

However, looks like Arial Unicode as shipped on WinXP, does have GDEF
glyph class array, but defines no classes for Hebrew.  This results
in Hebrew marks not getting their widths zeroed.  So, with this change,
we synthesize glyph class for any glyph that is not specified in the
GDEF glyph class table.  Since, from our point of view, a glyph not
being listed in that table is a font bug, any unwanted consequence of
this change is a font bug :).

Note that we still don't get the same rendering as Uniscribe, since
Uniscribe seems to do fallback positioning as well, even though the
font does have a GPOS table (which does NOT cover Hebrew!).  We are
not going to try to match that though.

Test string for Arial Unicode:

	U+05E9,U+05B8,U+05C1,U+05DC

Before:		[gid1166=3+991|gid1142=0+737|gid5798=0+1434]
After:		[gid1166=3+991|gid1142=0+0|gid5798=0+1434]
Uniscribe:	[gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]

Note that our new output matches what we were generating until July
2014, because the Hebrew shaper used to zero mark advances based on
Unicode, NOT GDEF.  That's 9e834e29.

Reported by Greg Douglas.

Add --with-icu=builtin option; fix compile error

The default tar-v7 is not good enough for us (99 char filename
limit), so I have had bumped to tar-pax.  We got one complaint
that someone's tar couldn't handle tar-pax.  Set to tar-ustar
which is ~13 years earlier than tar-pax and is good enough for us.

Bending to clang warnings...
https://bugs.chromium.org/p/chromium/issues/detail?id=593057

Fix build with HB_DISABLE_DEPRECATED

Originally the way Jonathan had written this was correct in
"continue"ing:

https://github.com/jfkthame/harfbuzz/commit/35e28c7a733eaffcd9f062b18d7db9fbb3d990fc#diff-ead86a33a5cc9ad7f6e6381031a0baddR199

When I rewrote his patch, I messed it up:

https://github.com/behdad/harfbuzz/commit/da132937989acb4d8ca9bd41c79f98750e7dda30#diff-ead86a33a5cc9ad7f6e6381031a0baddR209

the intended behavior was NOT to set found=TRUE and NOT to continue.
This was resulting in feature_index[table_index] being left unset.
Oops!

I had forgotten about those types.

Fix compile error in hb-icu.cc when ICU configured with
U_NO_DEFAULT_INCLUDE_UTF_HEADERS=1

When HB_DISABLE_DEPRECATED is defined, no code from hb-deprecated.h
should be used, even from within HB itself.

This makes defining HB_NDEBUG much less relevant, to the
point of irrelevance.  Sorry about all the fuss in previous
release!

API changes:
- If NDEBUG is defined, define HB_NDEBUG
- Disable costlier sanity checks if HB_NDEBUG is defined.

In 1.2.3 introduced some code to disable costly sanity checks if
NDEBUG is defined.  NDEBUG, however, disables all assert()s as
well.  With HB_NDEBUG, one can disable costlier checks but keep
assert()s.

I'll probably add a way to define HB_NDEBUG automatically in
release tarballs.  But for now, production systems that do NOT
define NDEBUG, are encouraged to define HB_NDEBUG for our build.

Saves some sweet time and binary size!