Oops!

That's not in the OpenType spec, but it's what MS and Adobe do.

Patch from Kenichi Ishibashi.

For two reasons:

1. User can always call hb_buffer_pre_allocate() themselves, and

2. Now we do a pre_alloc in add_utfX anyway, so the total number of
reallocs is limited to a small number (~3) anyway.  This just makes the
API cleaner.

We do a conservative estimate of the number of characters, but still,
this limits the number of buffer reallocs to a small constant.

We need this to set data on objects safely without worrying that some
other thread unsets it by setting it at the same time.

Since we already switched to accepting -1 as 'zero-terminated'.

A -1 text_length means: zero-terminated string.
A -1 item_length means: to the end of string.

hb_shape() now accepts a shaper_options and a shaper_list argument.
Both can be set to NULL to emulate previous API.  And in most situations
they are expected to be set to NULL.

hb_shape() also returns a boolean for now.  If shaper_list is NULL, the
return value can be ignored.

shaper_options is ignored for now, but otherwise it should be a
NULL-terminated list of strings.

shaper_list is a NULL-terminated list of strings.  Currently recognized
strings are "ot" for native OpenType Layout implementation, "uniscribe"
for the Uniscribe backend, and "fallback" for the non-complex backend
(that will be implemented shortly).  The fallback backend never fails.

The env var HB_SHAPER_LIST is also parsed and honored.  It's a
colon-separated list of shaper names.  The fallback shaper is invoked if
none of the env-listed shapers succeed.

New API hb_buffer_guess_properties() added.

Where causing issues for people with MSVC.

Buffer var allocation coming into shape

Mozilla Bug 669175 - Slow rendering of text sometimes in this case,
using direction: rtl

While the cluster fields of the glyph string are usually sorted, they
wouldn't be in special cases (for example for non-native direction).
Blindly using bsearch is plain wrong.  If we want to reintroduce this
optimization we have to make sure we know the buffer clusters are
monotonic and in which direction.  Not sure it's worth it though.

Should be all set now.

Makes way for adding arbitrary user_data support.

This was a bizzare piece of API that I inherited from cairo.  It has
been wrong adding them to cairo in the first place.  Remove them before
someone uses them!