Only write explicit tuple mins/maxes if there is an intermediate tent

[Hoolean]

This is a lossless optimisation that is also implemented in fontTools, and reduced gvar table size by ~50% when testing locally on a large variable font.

I inlined TupleBuilder as there was a precise ordering needed for converting the types, comparing values, and making the output conditional that was tricky to represent in the existing abstraction without lots of zipping and unzipping.

I tried a few functional patterns but couldn't find anything elegant without wider changes to types owing to the previous ordering, so thought it would be better to leave it inline and imperative and reach out for feedback first before doing anything more opinionated 😄

Before merging, this new logic would benefit greatly from unit test coverage too.

[Hoolean]

(clippy lints are valid, the trace!(...) should make a comeback before we merge, and the explicit return is left behind from when I was still chopping and changing things)

[cmyr]

Looks good! I think it would be possible to continue using the builder if we wanted, and change it so that build() returns (Tuple, Option<(Tuple, Tuple)>) but I also think it's fine inlined since it isn't used anywhere else.

I wouldn't worry about putting back the trace!, and I'll be happy to merge when CI is green.

[rsheeter]

We should be able to add test(s) to prove it works?

[Hoolean]

I've hit a road block adding tests: fontations' GlyphDeltas is public but its fields are not, and so intermediate_region cannot be inspected after construction.

We could make this field public, but I am tempted to argue that we make the wider change of moving the abstraction boundary lower into fontations, and treating this as serialisation logic.

e.g. give GlyphDeltas a Vec<(F2Dot14, F2Dot14, F2Dot14)> (or custom struct equivalent) and determine whether explicit intermediate coordinates are needed to be written at serialisation time.

I think this optimisation is higher-level than delta set optimisation but lower-level than IUP optimisation -- it is lossless, ttx does not expose it, and there has never been motivation to toggle it -- and so it may be more ergonomic there. We could avoid unzipping until serialisation time, ditch the assert that the tuple lengths are the same, and gain a bit more immutability for example.

Am happy to go either way; interested to hear your thoughts :)

[anthrotype]

I am tempted to argue that we make the wider change of moving the abstraction boundary lower into fontations

I also think this logic belongs to fontations

[Hoolean]

I'll put together a PR there to see how this looks

[Hoolean]

Moved to googlefonts/fontations#1345