refactor: More exoClasses have stateShape metadata

[erights]

Adds some of the stateShape metadata needed to get the benefit of #7444

Even when the shape of each property in the stateShape record is merely M.any(), we still get the full benefit of #7444 .

With more accurate shapes, which can be incrementally contributed later, we'll also get better error checking. If #6432 happens, then these more accurate shapes might also reduce storage as well as serialization/deserialization time and allocations. We'll see.

[turadg]

Looks fairly mechanical. I didn't review every item but I trust the changes since tests are passing.

[Chris-Hibbert]

1. Is this only a benefit for high cardinality objects? Is it clear that it's not a net cost for low-cardinality objects? AuctionBook is expected to be low-cardinality. I didn't look at others.
2. Is there no value to spending a little time making the types tighter than M.any()?

[erights]

1. Is this only a benefit for high cardinality objects? Is it clear that it's not a net cost for low-cardinality objects? AuctionBook is expected to be low-cardinality. I didn't look at others.

It is only a performance benefit for high cardinality objects. So yes, AuctionBook was lower priority than many others. For this PR, I just picked a few exoClasses to be the first experiment to see what difference #7444 makes, and to see if it breaks anything. As do this to more exoClasses, we should prioritize better.

2. Is there no value to spending a little time making the types tighter than M.any()?

Yes! But not in this PR. There are two anticipated benefits

• detect more bugs, though it has not yet actually detected any
• eventually, compression, if WIP feat: use pattern-based compression #6432 ever happens