Normally I would have added to_string / from_string like other types
have.  But since we don't use hb_color_t much, I'm not going to do that.
Although, if we did, we could use it in hb-view to parse colors...

Now to hb_color_t.

Will come in through <T> if desired.

Doesn't work though, ouch :(.  Need to figure out if it's unreasonable
to expect Null(T) inside hb_array_t<T> to see the later specialization
of Null for NameID.

We cannot use a nullable offset here though.

COLR table has one function: return layers for a glyph, and we expose exactly
that, so should just wire it through.  Also use sub_array() for verifiable
safety.

Also, BaseGlyphRecord's null object is enough.  We don't need to special-case
the not-found.

We never return parallel arrays from functions.  That's inconvenient
and hard to bind.

Implement has_data() for realz.

We don't expose "gid" in API.

Not sure if MSVC would be unhappy about this.

Sanitize always comes just before data member definitions, so
it's easy to cross-check.

When a struct is plain old data with no references, etc, it's okay
to mark its members public.

Fixed already but better to have anyway.

One didn't have minimized but it was only 164 B, so

[test] Unify font file opening across the tests