Improving ergonomics with a more-harfbuzz-like sanitize step

Currently we validate each table when it is read, and this validation does not chase offsets. This has two downsides: the first is that we need to do duplicate validation work each time we access a subtable, and the second is that we need to either check or unwrap the result type on each access, which is annoying.

I've been thinking about a possible pattern that would avoid this. Basically this would look like,

- Alongside `TableRef` we have a type, `CheckedTableRef`. (names to be bike-shedded)
- `TableRef` has a method that looks something like `check(&self) -> Option>`
- This method recursively resolves each offset, and calls `check` on the underlying table. It returns `Some` only if all offsets can be read.
- `CheckedTableRef` now has offset getters that return their target without having to perform validation, and without a `Result` wrapper.
- This mechanism would be opt-in, either at the level of codegen or simply by the caller; but this means that you might choose to only opt for the checked table in a place where re-reading is expensive, and where there is no recourse if an inner offset is broken (for instance this might make sense for a layout subtable, where we probably want to just skip the table if something is malformed)

Downsides that I can think of:
- more generated code
- more complicated API
- complicates consumer API: callers might want to have the ability to work with either the checked or unchecked version of some table, and I can't think of a great pattern for dealing with this? But maybe the answer is that this mechanism would only be used in places where we would be happy to bail on failure?