No functional change right now.

This makes a lot of code safer.  We only try modifying the object in one
place, after making sure it's safe to do so.  So, do a const_cast<> in
that one place...

Can be further optimized, but I think I didn't break anything.

Saves another 3% off Roboto shaping.

Towards reducing the cost of initializing skippy_iter()

Has no functional effect since reject was never used with
match_glyph_data.

Currently:

  - Initializing skippy is very expensive,

  - Our lookup accelerator (using set-digests) can be very ineffecite,

As such, we end up many times initializing skippy but then failing
coverage check.  Reordering fixes that.

When, later, we fix our accelerator to have truly small false-positive
rate (for example by using the frozen-sets), then we might want to
reorder these checks such that we wouldn't calculate coverage number
if skippy is going to fail.

This shows a 5% speedup with Roboto already.

I experimented with replacing use of hb_set_digest_t with this new
hb_frozen_set_t, hoping to get a huge speedup for busy lookups
(like kern lookup in Roboto), but I only got 6% speendup in Roboto
and 4% in NotoNastaliqUrduDraft :(.

Fix build with MSVC on CE

This code is C++ only. There isn't a single C++ compiler that fails to
understand the "inline" keyword, since it's required by C++98. Any
compiler older than C++98 is likely to choke on the template usage
further down, so this isn't necessary.

Moreover, the C++ standard says you cannot define macros.
[lib.macro.names] says "Nor shall such a translation unit define macros
for names lexically identical to keywords." -- technically, it's a
promise that the Standard Library headers won't do it, the wording means
that the entire translation unit won't do it, which implies no source
can do it.

MSVC complains about it:
fatal error C1189: #error : The C++ Standard Library forbids macroizing
keywords. Enable warning C4005 to find the forbidden macro.

Author: Thiago Macieira <thiago.macieira@intel.com>

As discovered on Chrome Mac:
https://code.google.com/p/chromium/issues/detail?id=452326

As discovered on Chrome Mac:
https://code.google.com/p/chromium/issues/detail?id=452326

This was originally broken in:

	commit 5a0eed3b
	Author: Behdad Esfahbod <behdad@behdad.org>
	Date:   Mon Aug 11 23:47:16 2014 -0400

	    [coretext] Implement vertical shaping

This is by no ways to promote non-Unicode encodings.  This is an entry
point that takes Unicode codepoints that happen to all be the first
256 characters and hence fit in 8bit strings.  This is useful eg in Chrome
where strings that can fit in 8bit are implemented that way, and this
avoids copying into UTF-8 or UTF-16.

Perhaps we should rename this to hb_buffer_add_codepoints8().  I'm also
curious if anyone would be really interested in hb_buffer_add_codepoints16().

Please discuss!

winrt_buildfixes

Just to keep Windows specific workarounds in a single place.

There is a _HBMemoryBarrier() wrapper function that emulates
MemoryBarrier() behavior when it is not defined.

There is no environment (like WinCE) and the basic version
of InitializeCriticalSection is unsupported.

https://codereview.qt-project.org/#/c/92496/

Before we were not accounting for possible differences in x_scale and
y_scale, as well as the signs of those.  All should be in good shape
now.