Spread BE kerning across threads

[rsheeter]

Builds on #642.

Numbers bounce around a bit run to run but mean + σ on branch is consistantly better than mean - σ on main.

$ cargo build --release && hyperfine --warmup 5 --prepare 'rm -rf build/' 'target/release/fontc ../googlesans/source/GoogleSans/GoogleSans.designspace'

# Linux
main   6.925 s ±  0.248 s
branch 6.356 s ±  0.217 s

# Mac
main  3.904 s ±  0.370 s
branch 3.828 s ±  0.037 s

Linux $ cargo build --release && rm -rf build/ && target/release/fontc ../googlesans/source/GoogleSans/GoogleSans.designspace --emit-timing:

Observations:

• fea is 15%
• font, which per Generating GPOS takes a long time #610 is mostly packing gpos, is 20%
• kernat should probably start sooner, such as right after glyph order
  • I need to take another pass at making sure we refer to kern instance not kern at :)

[cmyr]

So the main thing missing from all of this, as best I can tell, is some high-level overview of how it works: basically what are the different stages of the work and how to they fit together, what are the invariants at each stage, etc; I think that would be very useful to have somewhere.

[cmyr]

Just as a general observation but I prefer not to import these macros by name, and instead just call them as log::debug!("my message"). The main rationale for this is simply that it makes it easier to grep for all the places where you're logging. A secondary rationale is that there's a (loose) convention in Rust to avoid importing functions directly, and instead import their parent module.. I can't find a great source for this, but it's mentioned here by klabnik. I like this convention but am not zealous about it.

[rsheeter]

I think we do this relatively consistently; maybe file an issue and we'll fix it eveyrwhere plus add a presubmit?