Consistenize backend memory types to support persistent CPU mapping of `Buffer`s

Currently specifically Metal and Vulkan allocate memory in a way that makes them incompatible with persistently mapping CPU pointers for convenient access without extra calls.

This may have been done for performance reasons, but reading or writing currently requires careful use of the `map()` and `unmap()` semantics after https://github.com/llvm/offload-test-suite/pull/1113. Specifically Metal requires an `unmap()` to make CPU writes visible to the GPU (`MTLBuffer::didModifyRange()`), whereas Vulkan only supports `map()`ing readback buffers _after the GPU-fence (with `dst=HOST_READ` barrier) has been waited on_ so that it can perform the `vkInvalidateMappedMemoryRanges()` call. This split in semantics can become extra cumbersome when developing cross-platform tests, as one might easily miss this mis-match between flushing semantics in both backends. I did not yet take Dx12 into account.

---

If this sort of performance-split is desired, it simply means the existing `CpuToGpu`/`GpuToCpu` abstraction isn't expressive enough when it requires such platform divergence. It also doesn't work very well for UMA for example, where often times most if not all buffers are `DEVICE_LOCAL | HOST_VISIBLE` and likely also cached and coherent with no reduced aperture.

Start by comparing the Metal and Vulkan buffer allocation and map/unmap semantics described in the issue, then inspect the CpuToGpu/GpuToCpu abstraction. Account for the unconsidered Dx12 backend and determine whether the abstraction should represent platform differences or standardize persistent mapping. Done means cross-platform buffer access has consistent, documented semantics and tests cover the relevant synchronization behavior.

Written by the indexing model from the issue text.