Uniscribe does that, this make comparing results to Uniscribe
easier.

We never use them in fact...

I'm just adjusting these as I better understand the requirements of
the code and the guarantees of each operation.

From https://bugs.freedesktop.org/show_bug.cgi?id=45166

We don't care about linearizability, so unprotected int read/write
are enough, no need for expensive memory barriers.  It's a cache,
that's all.

According to:
http://msdn.microsoft.com/en-us/library/65tt87y8.aspx

MemoryBarrier() is the right macro to protect these, not _ReadBarrier()
and/or _WriteBarrier().

As pointed out by Jonathan Kew.

The old code was doing nothing.

Still got to find an example font+string that makes this matter, but
need this for fixing synthetic GDEF anyway.

From:
http://people.mozilla.org/~jdaggett/tests/cjkcompat.html

To be used for cmap and advance caching if desired.

They can be macros on some systems.  Eg. mingw32.

Computes all the glyphs that may be generated given a font and
set of Unicode characters.

The order of the Unicode characters is irrelevant.

Sample output:

behdad:util 0$ ./hb-ot-shape-closure Doulos\ SIL\ Regular.ttf f
f f_f

behdad:util 0$ ./hb-ot-shape-closure Doulos\ SIL\ Regular.ttf i
i

behdad:util 0$ ./hb-ot-shape-closure Doulos\ SIL\ Regular.ttf fi
f f_i f_f_i f_f i

behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf ب
uni0628 uni0628.init uni0628.medi uni0628.fina

behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf ا
uni0627 uni0627.fina

behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf با
uni0627 uni0627.fina uni0628 uni0628.init uni0628.medi uni0628.fina

behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf با --no-glyph-names
5 6 133 134 135 136

Testing with old Deva spec this reduces failures.
Test sequence: U+0915,U+094D,U+0930.

This reverts commit 0831061e.