storage.filesystem should encode move records with relative version numbers

[jkomoros]

Discovered when working on #755. Using SeatPlayer logic in existing games will require considerable surgery on existing goldens, including splicing in new moves between existing moves.

Also related to #701

Because states are diffed from the record in front of them, it's easy to splice in states. But move records are encoded literally, which means their version number and initator fields need to be manually fixed up. (Blargh!)

Instead, the version number and initiator should be derived directly.

If the Version field is -1, that means, "return the literal count, and my initiator is also relative". Initiator fields are then interpreted as applying their version number and adding to the initiator version to get the actual value.

Records can be in relative or absolute move version mode, as detected by whether the Version field in the record is -1 or not.

Ideally we'd then be able to fix up existing goldens, but it might not be that big of a deal to just manually fix them up for now.

[jkomoros]

The data should not be kept in memory in the relative format, it should be transformed when read from disk and when written to disk only

[jkomoros]

... Ah crud, the state patches also encode the version. >:-[

[jkomoros]

... Why does state even encode a version number?

It doesn't need to. Just don't emit it in state.customMarshalJson, and make manager.stateFromRecord also take the version (it's only used in one place, and in tests internal to the package).