Fixes https://github.com/libass/libass/issues/212

Test from https://github.com/behdad/harfbuzz/issues/223

I forgot that we do run hb-fuzzer on tests in shaping/tests/fuzzed.tests.

Fixes https://github.com/behdad/harfbuzz/issues/223

Right now we cannot test this because it has to be tested using hb-fuzzer.
We should move all fuzzing tests from test/shaping/tests/fuzzed.tests to
test/fuzzing/ and have its own test runner.  At that point, should add
test from this issue as well.

Not going to do with util/, but is convenient here.

Fixes https://github.com/behdad/harfbuzz/issues/227

Fixes https://github.com/behdad/harfbuzz/issues/169

This is what Microsoft's implementation does.  Marks that need advance
need to add it back using 'dist' or other feature in GPOS.  Update tests to
match.

Fixes https://github.com/behdad/harfbuzz/issues/211

What happens in that bug is that a mark is attached to base first,
then a second mark is cursive-chained to the first mark.  This only
"works" because it's in the Indic shaper where mark advances are
not zeroed.

Before, we didn't allow cursive to run on marks at all.  Fix that.
We also where updating mark major offsets at the end of GPOS, such
that changes in advance of base will not change the mark attachment
position.  That was superior to the alternative (which is what Uniscribe
does BTW), but made it hard to apply cursive to the mark after it
was positioned.  We could track major-direction offset changes and
apply that to cursive in the post process, but that's a much trickier
thing to do than the fix here, which is to immediately apply the
major-direction advance-width offsets...  Ie.:

https://github.com/behdad/harfbuzz/issues/211#issuecomment-183194739

If this breaks any fonts, the font should be fixed to do mark attachment
after all the advances are set up first (kerning, etc).

Finally, this, still doesn't make us match Uniscribe, for I explained
in that bug.  Looks like Uniscribe applies minor-direction cursive
adjustment immediate as well.  We don't, and we like it our way, at
least for now.  Eg. the sequence in the test case does this:

- The first subscript attaches with mark-to-base, moving in x only,
- The second subscript attaches with cursive attachment to first subscript
  moving in x only,
- A final context rule moves the first subscript up by 104 units.

The way we do, the final shift-up, also shifts up the second subscript
mark because it's cursively-attached.  Uniscribe doesn't.  We get:

[ttaorya=0+1307|casubscriptorya=0@-242,104+-231|casubscriptnarroworya=0@20,104+507]

while Uniscribe gets:

[ttaorya=0+1307|casubscriptorya=0@-242,104+-211|casubscriptnarroworya=0+487]

note the different y-offset of the last glyph.  In our view, after cursive,
things move together, period.

No effect.

Part of fixing https://github.com/behdad/harfbuzz/issues/211

Right now the position_finish_advances() is empty.  To be used for
spacing attachments proposal later.

Will do nothing.  Just useful for merging two functions.

Differentiate, using new attach_type().

No behavior change.  Preparing to unify how cursive and mark attachments
work.

Is confusing.  I already hit it myself.  Remove.  We can optimize
ASCII based on Unicode properties.  But should not do based on
assumptions on the font.

They had an invalid LookupFlag (32).

See thread at:
https://lists.freedesktop.org/archives/harfbuzz/2016-February/005462.html

Enable Build of HarfBuzz under Visual Studio using NMake Makefiles

Add into the NMake Makefiles to build the DirectWrite shaping backend,
but as PR #134 mentions, this is considered to be in an experimental state,
so don't include this in the build by default for now.  This is most probably
going to replace the Uniscribe backend eventually, since DirectWrite is meant
to be Uniscribe's replacement, and is needed for Windows Store apps if a
system shaping API is to be used.

This adds to the autotools build system so that the (experimental)
DirectWrite support for HarfBuzz is built (and dist'ed).

This adds a set of NMake Makefiles that can be used to build HarfBuzz, from
the standard basic build building the minimal HarfBuzz DLL (consisting
of OpenType, fallback and Uniscribe support only), to a full fledged build
consisting of GLib and FreeType support, as well as building the utilities,
the test programs in src/ and test/api, and HarfBuzz-ICU and
HarfBuzz-GObject, and up to building the introspection files.  This means a
flexible build mechanism is supported here, so anything that is supported
for a Windows build (code-wise), should all be supported by this build
system.

As in an earlier commit, the source listings are shared with the autotools
builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and
this set of NMake Makefiles will transform these lists into the form they
want.

In the current form, all the test programs in test/api pass, and this has
been checked successfully with 'make -j8 distcheck'.

This adds a pre-configured config.h template that can be used for Visual
Studio builds, where autotools is not normally available.  This has the
configs that are suitable for Visual Studio builds, as well as all the
features used for Windows builds enabled (HAVE_OT, HAVE_FALLBACK and
HAVE_UNISCRIBE).

Note that the optional features are not enabled here, they are enabled by
/D's (or -D's) in the NMake Makefiles as requested.

This moves all the source listings in src/Makefile.am,
src/hb-ucdn/Makefile.am and util/Makefile.am into separate Makefile
snippets, so that they may be shared between different Makefile-based
build systems, such as NMake for Visual Studio.

Hopefully
fixes https://github.com/behdad/harfbuzz/issues/214

Add usermanual chapter on cluster levels