refactor(store): optimize table libraries

[dk1a]

changes to 2 files in store's codegen (everything else is autogenerated)
minor stuff to finish table libs

any more attempts at table optimizations likely hurt code too much: #1286 #1183

[changeset-bot]

🦋 Changeset detected

Latest commit: 20e5c80

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 26 packages

Name	Type
@latticexyz/store	Patch
@latticexyz/cli	Patch
@latticexyz/dev-tools	Patch
@latticexyz/react	Patch
@latticexyz/std-client	Patch
@latticexyz/store-cache	Patch
@latticexyz/store-indexer	Patch
@latticexyz/store-sync	Patch
@latticexyz/world	Patch
@latticexyz/ecs-browser	Patch
@latticexyz/block-logs-stream	Patch
@latticexyz/common	Patch
@latticexyz/config	Patch
create-mud	Patch
@latticexyz/gas-report	Patch
@latticexyz/noise	Patch
@latticexyz/phaserx	Patch
@latticexyz/protocol-parser	Patch
@latticexyz/recs	Patch
@latticexyz/schema-type	Patch
@latticexyz/services	Patch
@latticexyz/solecs	Patch
solhint-config-mud	Patch
solhint-plugin-mud	Patch
@latticexyz/std-contracts	Patch
@latticexyz/utils	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[alvrs]

let's add a small changeset

[dk1a]

a few nuances I feel like I should clarify:

• I think we've decided to not do changesets for stuff that's not exported, like tests
• do we need changesets for internal things (like this gas PR) that are exported but don't affect API/functionality (I guess you could consider gas costs as functionality though)?
• I assume more detailed changesets for API stuff are good, but do we want details for internal changes?

[alvrs]

We should add a changeset for anything that should trigger a version increase (= stuff that updates code that lands in a user's project, even if it's internal, but not necessarily tests or docs). If the change is an internal refactor or fixes something that was supposed to be working before, it's a patch. If it adds a non-breaking feature it's a minor and if it's a breaking change it's a major.

For patch changes a one-liner is totally fine. For new features it depends on the size of the feature, but an example for how to use it is always nice. For breaking changes we need more descriptions for how to update and context on the change.