In the now obsolete ICU code path, we cache the layout tables in native
memory so that when requested by ICU we can just hand the pointer,
saving the overhead of copying the Java array for every call to layout.

In the harfbuzz path we aren't doing that which surely must slow down
repeated calls at least somewhat.

Note that harfbuzz still will likely copy and sanitise the table each time
we create a face object but fixing that needs a deeper understanding
(perhaps too deep) of how we can re-use harfbuzz objects across
calls to shape. Something to consider later.

The more isolated fix is to cache the tables on the font and just
hand a reference to HB.
We probably need to set HB_MEMORY_MODE_READONLY unless
we can establish that and WRITE HB will do doesn't invalidate
the initial state and is idempotent.

We also need to stop it calling free and manage the storage
as part of the lifecycle of the Font2D. That latter code already exists
so there should be no new code needed there.