API changes:
- If NDEBUG is defined, define HB_NDEBUG
- Disable costlier sanity checks if HB_NDEBUG is defined.

In 1.2.3 introduced some code to disable costly sanity checks if
NDEBUG is defined.  NDEBUG, however, disables all assert()s as
well.  With HB_NDEBUG, one can disable costlier checks but keep
assert()s.

I'll probably add a way to define HB_NDEBUG automatically in
release tarballs.  But for now, production systems that do NOT
define NDEBUG, are encouraged to define HB_NDEBUG for our build.

- use '-w' instead of '\<...\>' for check-header-guards
  grep manpage says these are the same

- put '-q' first in the grep options

- move VAR into hb-private.hh

- hb-font-private.hh - use [VAR] instead of [] for variable array

The generic template operator overloading was causing more problems than it
solved.  Eg:

https://github.com/behdad/harfbuzz/pull/163
https://github.com/behdad/harfbuzz/issues/175

So, just use macros.

Fixes https://github.com/behdad/harfbuzz/issues/175
Fixes https://github.com/behdad/harfbuzz/pull/178

Use the DEFINE_ENUM_FLAG_OPERATORS macro in winnt.h on Visual Studio,
which defines the bitwise operators for the enumerations that we want to
mark as hb_mark_as_flags_t, which will take care of the situation on newer
Visual Studio (>= 2012), where the build breaks with C2057 errors as the
underlying types of the enumerations is not clear to the compiler when we
do a bitwise op within the declaration of the enumerations themselves.

Also disable the C4200 (nonstandard extension used : zero-sized array in
struct/union) and C4800 ('type' : forcing value to bool 'true' or 'false'
(performance warning)) warnings as the C4200 is the intended scenario and
C4800 is harmless but is so far an unavoidable side effect of using
DEFINE_ENUM_FLAG_OPERATORS.

Now that we have a buffer-wide scratch flags facility, use it to
optimize away a few passes.

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

Or I think it should.

Borrowed from https://bugzilla.mozilla.org/show_bug.cgi?id=1215411

User can define hb_malloc_impl, etc, to name of custom allocator functions
that have the same signature as malloc.

Not functional change (expected!).

Needed for upcoming merge-clusters fix.

Unused right now.

And add check to FLAG()

definition and usage of the words

https://bugzilla.mozilla.org/show_bug.cgi?id=1167119

This reverts commit 89cbd4d9.

See discussion:
https://bugzilla.gnome.org/show_bug.cgi?id=747772

Not sure we have any right now; motivated by this:
https://bugzilla.gnome.org/show_bug.cgi?id=747772

Based on patch from Björn Breitmeyer

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>

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/

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=84491

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