Oops.

Unused, and why here and not in other functions...

See comments.

Let's see if I break any bots.  But yeah, it wasn't accepting a
non-const pointer.  It just happens that we don't use that in the
code it seems.

Both to save ops, and also because lambdas don't implement operator!=,
so this was failing in range-based for loop if a lambda was passed to
hb_map() or hb_filter().  Just check end-condition assuming that we
are comparing to .end() or iterators that are otherwise derived from
current iterator.  Ie. don't compare things that are expected to be
in common.

To fix https://travis-ci.org/harfbuzz/harfbuzz/jobs/532693197

It may break things, lets see

Fails locally.  Trying to understand.  Sigh

Apparently there's different overload resolution rules that apply, at
least with some (older?) version of gcc.

hb-ot-name-table.hh: In member function ‘void OT::name::accelerator_t::init(hb_face_t*)’:
hb-ot-name-table.hh:244:62: error: ambiguous overload for ‘operator+’ (operand types are ‘hb_blob_ptr_t<OT::name>’ and ‘OT::NNOffsetTo<OT::UnsizedArrayOf<OT::IntType<unsigned char, 1u> > > {aka const OT::OffsetTo<OT::UnsizedArrayOf<OT::IntType<unsigned char, 1u> >, OT::IntType<short unsigned int, 2u>, false>}’)
       this->pool = (const char *) (const void *) (this->table+this->table->stringOffset);
                                                              ^
hb-ot-name-table.hh:244:62: note: candidates are:
hb-ot-name-table.hh:244:62: note: operator+(const C*, long int) <built-in>
hb-ot-name-table.hh:244:62: note: operator+(const char*, long int) <built-in>

This reverts commit 01912efb.

Actually this didn't break things.  Fixing

Reverts 57f65ae9

Caused ambiguous-overload on some gcc...

See comments.

We should add a bot for it
Part of #1652

Fixes an unused function warning when building with HB_NO_SUBSET_LAYOUT
as part of the Chrome build.

https://github.com/grigorig/ucdn/issues/23

Part of https://github.com/harfbuzz/harfbuzz/issues/1652

No idea where these appear from...