This one:

  map->mask = (1 << (next_bit + bits_needed)) - (1 << next_bit);

before the fix, the shift was done as an int, causing overflow
if it ever got to 1 << 31.  Sprinkle 'u's around.

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=634805

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

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

Fixes https://github.com/grigorig/ucdn/issues/12

This is based on bug reports that have been filed against Firefox since it
updated to a version of harfbuzz that uses zeroing by GDEF rather than by
Unicode. I'm sure there are a bunch more font versions that should also be
included; these are just the ones I have on hand and have confirmed as having
bad GDEF data.

Given how the list here is growing, I think we should reconsider the approach,
and perhaps revert to zeroing by Unicode instead.

Fixes https://github.com/behdad/harfbuzz/issues/264
Fixes https://github.com/behdad/harfbuzz/pull/266

Fixes https://github.com/behdad/harfbuzz/issues/236
Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=627953

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=614647
If allocation fails, we might be leaving junk behind.  At least
clear it up.

Prior to this change the function `FT_Error FT_Done_Face(FT_Face *)` was
called through a pointer with the signature `void (void *)` resulting in
undefined behaviour.

Fixes https://github.com/behdad/harfbuzz/pull/271

Part of https://github.com/behdad/harfbuzz/issues/277

Addressing Nikolay Sivov reviews on harfbuzz mailing list

No longer noticeable memory increase on create/destroy iterations,
highly better than current state of uniscribe backend

This reduces memory consumption of my iterated font create/destroy cycle test
significantly and makes it much better than uniscribe backend even

With help of
https://dxr.mozilla.org/mozilla-central/source/gfx/2d/NativeFontResourceDWrite.cpp

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

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

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

From draft update to USE.

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

Hopefully we got the logic right.

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

With javatext.ttf, the reodering medial Ra gets its advance width
zero'ed in Uniscribe implementation, and the font adds the advance
back.  Our Indic shaper does not do that, but USE does.  So, route
Javanese through USE.  That's what Microsoft does anyway.  Test:

  U+A9A5,U+A9BA

This also seems to fix the following sequence, and variations thereof:

  U+A99F,U+A9C0,U+A9A2,U+A9BF

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

These are frozen, so good time to add.

To make a release...