Was good idea, but with C++ types with constructor/destructor, was getting in
the way as compiler was destructing those items where it was not desired.
Since C++ does not allow zero-sized arrays, just remove it...

This resulted from confusion previously...

Saves 4 or 8 bytes per object on 64bit archs.

I keep forgetting that primitive types are NOT initialized during construction. :|

Newer compilers / language allows structs with constructor in union.
So, this was not actually testing anything.  Indeed, the recent
change in DISALLOW_COPY *is* making some of our types non-POD.
That broke some bots.

Just remove this since it wasn't doing much, and I'd rather have
DISALLOW_COPY.

Sorry for the noise, downstream custom builders.  Please adjust.

Found and fixed a couple bugs.

Found a couple multithreading issues.  Marked them with "XXX-MT-bug".

To help TSan and be more "correct".

Fixed the crasher in it.

This reverts commit 21fa170f.

Is crashing.  Oops.

Hopefully fixes bots.

Towards using Null object for nil objects.

This saves each object allocation 72 bytes.  Now object overhead is just
16 bytes (on x86) instead of 88 bytes. Neat.

For consistency.

This reverts commit 5daf3bd4.

If other atexit callbacks try to destruct the objects we destruct
in atexit callbacks, bad things will happen.

I'll come up with some other way to catch premature destruction
of HB-owned objects.

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

Part of fixing https://github.com/behdad/harfbuzz/pull/605

Such that client cannot accidentally destroy them, even though that
will be a bug in their code...

Previously we were setting refcount of freed objects to the inert value, which
was harmful because it caused further destroy()s of the freed object to NOT
call free() and hence hide the bug.  Indeed, after eb0bf3ae test-object
was double-free'ing objects and this was never caught on Linux.  It only was
caught as crashing on Mac.

Now we poison refcount upon freeing and check that it's valid whenever reading
it.  Makes test-object fail now.

s/atomic_int/atomic_int_impl/ and s/atomic_ptr/atomic_ptr_impl/
to bring it in par with hb_mutex_impl_t, then re-introduce
hb_atomic_int_t as a wrapper around hb_atomic_int_impl_t.

In hb_reference_count_t, make it clear the non-atomic get and set
are intentional due to nature of the cases they are used in
(comparison to -1 and the debug output/tracing).

This reverts commit 9c80cbc8.

Fixes https://code.google.com/p/chromium/issues/detail?id=403594

In preparation for fixing:
https://code.google.com/p/chromium/issues/detail?id=403594

We are not using it for anything lse it seems.