Align buffer blocks in saved state.

[rndmcnlly]

This wastes some bytes for the rare irregular buffer, but it opens up the possibility of running block-based deduplication that reaches across multiple large system components. For example, we can detect when a block from disk has one or more copies in main memory.

In a small experiment I ran to choose an optimal block size for memory blocks, I found 512 was the best (balancing frequency of block repetition with the storage needed to store block ids). However, a block size of 256 was nearly as good. Further, this block size matches the one used in the Buffer system for caching lazily loaded disk blocks. As a result, it seems like the best overall choice.

Context: I'm working towards losslessly compressing a sequence of savestates to create a video-like record of interactive performances. If potentially repetitive elements of state files are block-aligned, I can blindly deduplicate saves without inventing a new storage format.

[rndmcnlly]

I mistakenly thought that changing the alignment would only impact saving (in the same way that you can often improve an encoder without needing to make analogous changes to a decoder). However, now I see that the restoration process is currently sensitive to the alignment because it needs compute derive buffer_block_start given only info_block.length. I can see a way to make the restoration process alignment-agnostic (one simple solution is storing alignment information in the info block itself), but it would involve bumping STATE_VERSION and breaking support for old saves.

Meanwhile, I'm getting better at using GitHub, so I'll stop making these dead-end PRs with half-baked ideas. I now know how to actually run the tests for myself.

Closing.