Every time I have to study these to understand why a change is right..

Fuzzer caught it:

==14==ERROR: AddressSanitizer: stack-use-after-return on address 0x7fca2ed7a3e0 at pc 0x0000006057aa bp 0x7ffc3290f1d0 sp 0x7ffc3290f1c8
READ of size 4 at 0x7fca2ed7a3e0 thread T0
SCARINESS: 55 (4-byte-read-stack-use-after-return)
    #0 0x6057a9 in OT::SingleSubstFormat2::subset(hb_subset_context_t*) const /src/harfbuzz/src/./hb-ot-layout-gsub-table.hh:194:40
    #1 0x5ff921 in hb_subset_context_t::return_t OT::SingleSubst::dispatch<hb_subset_context_t>(hb_subset_context_t*) const /src/harfbuzz/src/./hb-ot-layout-gsub-table.hh:256:13

I can't reproduce locally, but many of the bots are failing because of this
as well.

It's a pity that operator-> must return pointer.  Ugh.  Why?!

Not sure why I don't get it, but this warning:

warning: base class ‘struct hb_iter_fallback_mixin_t<hb_array_t<const OT::UVSMapping>, const OT::UVSMapping&>’ should be explicitly initialized in the copy constructor [-Wextra]

Using decltype() instead.

Seprate namespace, cleaner, more clear.

I had used Null to make one of the bots happy before.  Not going
to bend to such demands anymore..

The mystery failure had to do with SFINAE failure because the template
function involved was accessing ::iter_t of a type that was also named iter_t.
In this context, apparently:

warning: ISO C++ specifies that qualified reference to 'iter_t' is a
constructor name rather than a type in this context, despite preceding 'typename' keyword
[-Winjected-class-name]

We use a new macro, also called hb_iter_t(), to get iterator type of
a type.  This uses declval/hb_decltype, and has the added benefit
that it returns correct type for const vs non-const objects, if they
have different iterators.

Fixes https://github.com/harfbuzz/harfbuzz/issues/1553

Untested.

Untested.