Expand resource copying APIs

[Sergio0694]

Closes #158

This PR includes additions and improvements to all resource copying APIs, as detailed in the linked issue.

cc. @hawkerm for review 😄

[hawkerm]

Going to see if I can test out with the sample I was building, went though with some questions/comments though for you. Thanks! 😊

[hawkerm]

These were the weird failing tests right? Known to fail sometimes locally on certain machines?

[hawkerm]

Still had to modify the IShaderRunner interface, but think that was expected still (but worked to copy!):

public void Execute(ReadWriteTexture2D<Rgba32, Float4> texture, TimeSpan timespan);

[Sergio0694]

@hawkerm That is correct, those tests are somewhat bugged, but only on some machines and only under very specific cases. I'll see if I can get a repro together this weeked so that I can ping the D3D12MA engineer as well as the WARP team if needed 😄

And yes, changing that input texture is something we can look into in another PR.
What was your use case again for needing to copy it?

[hawkerm]

And yes, changing that input texture is something we can look into in another PR. What was your use case again for needing to copy it?

For #137 to be able to grab a copy of the result texture to pass in as input to the next run of the shader. As the texture passed in is empty each loop through right?

Realizing though that if I just have the buffer texture array anyway I can just do the calculations beforehand from that and store it in itself and may be the same... Was just thinking it may make math easier. I'll play around a bit more...

[Sergio0694]

"For #137 to be able to grab a copy of the result texture to pass in as input to the next run of the shader."

Ah, right. Yeah in that case you'd need a temporary buffer every frame otherwise you'd have shader invocations do side effect on the other pixels that are being read by other invocations (if every invocation is not just reading a single pixel at that corresponding location, but a window of pixels or any other group of pixels in general), and things would get messed up.

"As the texture passed in is empty each loop through right?"

No, the input texture will always have the data from the previous frame. So if that's enough for you and you're just having each pixel read on the corresponding pixel from the previous frame, you don't really need the additional temporary buffer.