[dx11] add new memory/buffer management code

[fkaa]

Makes Memory keep track of ranges that buffers are bound to and allows for multiple buffers to be bound to the same Memory now.

This gets us around 50% green in dEQP-VK.api.buffer

The other 50% is mostly because of an annoying limitation: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476085(v=vs.85).aspx

D3D11_BIND_CONSTANT_BUFFER
Bind a buffer as a constant buffer to a shader stage; this flag may NOT be combined with any other bind flag.

So buffers that are both uniform buffers & other things need to duplicate data? 😢

Fixes #issue
PR checklist:

• make succeeds (on *nix)
• make reftests succeeds
• tested examples with the following backends:

[fkaa]

Preface: Memory is implemented like this in the PR:

0.........................size
+----------------------------+
|        Memory              |
+----------------------------+
A..B  C.....D         E...F

1 Staging buffer which gets mapped (and should be used to copy from/to on flush/invalidate):
  (0..size, ComPtr<Buffer>)

*N* Resources:
  (A..B, ComPtr<Resource>),
  (C..D, ComPtr<Resource>),
  (E..F, ComPtr<Resource>),

Went ahead and tried to implement proper flush/invalidate behavior on a branch based off of these changes and ran into some trouble:

1. DX11 doesn't have permanently mapped buffers, so all the flushing and invalidation has to be emulated, no big deal.
2. With the current approach, on mapping memory, we hand out the pointer for the STAGING buffer covering our memory region.
   • We are not allowed to CopySubresourceRegion from or to our STAGING buffer while it's mapped. The copying from can kinda be worked around by using UpdateSubresource with the mapped buffer pointer as source.
   • Unmapping, then mapping again would not work, since we would let go of the pointer that the user is holding.

So while the current approach might sound nice on paper (at least to me) it kinda falls apart when trying to have one big STAGING buffer.

Potential solution to this could be to just use Vec<u8> (or virtual memory?) to act as the pointer we hand out, and flushing/invalidating would copy to & from this vec and could do some chunking of the flushed/invalidated ranges to make do with one fixed size staging buffer.

@gfx-rs/directxers any opinions?

[fkaa]

Closing in favor of #2149