Mapping scratch memory as PROT_NONE can cause /proc/.../maps divergence

Found this a while back but have neglected to file: during recording, we obviously map scratch as PROT_READ|PROT_WRITE, but during replay we map it as PROT_NONE to catch illegal accesses (should never be touched). When the kernel display /proc/maps, it coalesces subsequent anonymous pages with the same metadata. So when, during replay, the protection bits of scratch segments differ, then the kernel's coalescing can differ as well.

There's an outside chance that a task reading its own /proc/maps would be affected (maybe FF does that for about:memory?), but it's definitely been a problem for checksumming, because the checksummed segments change.

I hacked around this by not changing the protection bits, but a better fix is to name the scratch regions by allocating them from /dev/shm. That makes them non-anonymous so not coalescable. Also makes it easy to quickly identify scratch regions, which is a big pain otherwise, and extremely annoying when they get coalesced.

Trace how scratch memory is mapped during recording and replay, and compare the resulting /proc/maps entries and checksummed segments. Investigate allocating scratch regions from /dev/shm so they remain separately identifiable and non-coalescable; done means replay no longer causes mapping or checksum divergence.