Generating GPOS takes a long time

If I print the time for `bytes_for` in `fontbe/src/font.rs` GPOS takes ~10x GSUB which takes ~50x the next table in line:

```
$ cargo build --release && rm -rf build/ && time target/release/fontc ../googlesans/source/GoogleSans/GoogleSans.designspace
...
bytes_for Avar took 0.0ms
bytes_for Cmap took 0.1ms
bytes_for Fvar took 0.0ms
bytes_for Head took 0.0ms
bytes_for Hhea took 0.0ms
bytes_for Hmtx took 0.0ms
bytes_for Glyf took 0.3ms
bytes_for Gvar took 0.6ms
bytes_for Loca took 0.0ms
bytes_for Maxp took 0.0ms
bytes_for Name took 0.1ms
bytes_for Os2 took 0.0ms
bytes_for Post took 1.7ms
bytes_for Stat took 0.0ms
bytes_for Hvar took 0.1ms
bytes_for Gpos took 1025.9ms
bytes_for Gsub took 85.5ms
bytes_for Gdef took 0.3ms

real 0m6.334s
```

GPOS is about 16% of the total build time (real). We know we generate over-large GPOS tables (https://github.com/googlefonts/fontc/issues/593), that probably doesn't help.

https://github.com/googlefonts/fontc/pull/611 is my exploration that led to discovering this; I had assumed if I did everything except layout ahead it would help but it made no real difference which led me to the surprising bytes_for breakdown.

Start in fontbe/src/font.rs at the bytes_for timing path and reproduce the reported cargo build with the GoogleSans designspace. Compare Gpos generation with Gsub and the other tables, and review the exploration in pull request 611 plus the oversized-table context in issue 593. Done means the GPOS generation bottleneck is reduced and the timing can be verified against this reproduction.

Written by the indexing model from the issue text.