Proposal: Consider using capture analysis to reduce replay memory

Prior to starting execution of a replay stream we currently reserve blocks of memory for the touched chunks of application-observed memory. These blocks are collapsed down into a single large contiguous allocation, and observed pointers are remapped into this replay allocation. For every touched pointer in the captured application address space, we have a corresponding **unique** replay pointer.

The majority of API commands do not store pointer parameters into the state, and so are not *'captured'*.

This is a proposal to:
* Perform capture analysis on all pointer parameters to distinguish those that are potentially used after the command returns and those that are not.
* For reads and writes on buffers derived from pointers that **are not** captured, use a separate **single, reusable** allocation to store the per-command data. Whenever a command read or writes data, a simple stack based allocator will reserve a corresponding block for that read/write. Between commands this allocator will be reset, causing the next command's allocator to reuse the same memory. The actual replay-allocated buffer will be sized big enough to hold the largest number of bytes accessed by a single command in the replay stream. Note: this proposed allocator is already implemented as the [`Builder.AllocateTemporaryMemory()` function](https://github.com/google/gapid/blob/1077321bb27f3046c78df31a272be44369e4d1cd/gapis/replay/builder/builder.go#L195).
* For reads and writes on buffers derived from pointers that *are* captured, use the existing buffer management strategy.

I suspect (but will need to get some hard numbers) that this will dramatically reduce the amount of memory allocated for a single replay.