mini-RFC: add 'compile_size' method to FontWrite trait

Several times now I've run into situations where it would be helpful to know how many bytes the compiled representation of a given table will require, before actually compiling it.

This could potentially be helpful for things like table splitting; currently we do splitting by manual byte-mucking after attempting an initial compilation. With this change it would become possible for us to determine which splits are required ahead of time, which would let us implement these algorithms entirely in write-fonts, which would be a cleaner and more idiomatic solution.

One problem with this idea is that the sizes that we would calculate would not account for the table-packing algorithm's ability to deduplicate identical tables, which can significantly decrease table sizes in some cases. In effect, the size returned by this method would represent an upper bound. I think this is still useful, since in cases such as table splitting the only consequence might be that we unnecessarily split tables that are very near the overflow limit anyway, which seems okay; we would still be producing valid output.

This should also be quite easy to implement, since we already need to know how to calculate the sizes and lengths of everything in codegen, in order to correctly parse tables.

The main downsides is that this is not 100% necessary work, and it adds code that we have to compile and maintain.

Start with the FontWrite trait and the existing size and length calculations in codegen. Read the write-fonts table-splitting and table-packing paths to understand how an upper-bound compile size would be used and where deduplication affects it. Done means the API and size semantics are agreed and the resulting split decisions remain valid.

Written by the indexing model from the issue text.