This CL updates how we restore buffer data after the client has
unmapped it.  We do this because we have no visibility into
whether the buffer has been changed while mapped.

Tracking a buffer map/unmap pairing by target as we have been is
insufficient as apps can bind multiple buffers in succession before
rebinding and unmapping selectively.

To avoid this, we change our buffer data resource tracking to use
the buffer ID instead of target.

Also, since the app can map multiple buffers, we need to track the
active buffer during MapBufferRange so we can use it during replay
to restore from the appropriate handle.  This is a deferred
operation, so we store it as a new member of the ParamBuffer to
preserve the information.

Test: Temple Run capture and replay
Bug: b:152512564
Bug: angleproject:3662
Change-Id: I1d3f594b496e5675e814b82acb4a238f845e26d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2128328
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>