Issue title: D2D bug: CanvasVirtualBitmap makes a mess of PNGs in certain situations.
 Issue body: This is a bug in ID2D1ImageSource and ID2D1TransformedImageSource presumably. Here is what is possible to produce by combining a CanvasVirtualBitmap created from a PNG, a Transform2D effect with non-linear interpolation, a Border effect to tile it, and a Blend effect to blend with a base image.

![png-scale-tiling-issue](https://user-images.githubusercontent.com/10088503/93766536-76bc1200-fc0e-11ea-9a56-3f016dfaf64d.png)

The cracked texture (which is the CanvasVirtualBitmap PNG) should be uniformly tiled across the image, but there are a load of artefacts/garbage displayed.

This situation happens in two circumstances that I've noticed. The first is simply CanvasVirtualBitmap (from PNG) -> Transform2DEffect with non-linear interpolation (not sure if it ever occurs with linear as well) -> render. But it only happens in this case if the Transform2DEffect is being reused having previously been used with a different image source. The second situation, which is more complicated, is the one shown above, which is CanvasVirtualBitmap (from PNG) -> Transform2DEffect with non-linear interpolation (not sure if it ever occurs with linear as well) -> tile using BorderEffect -> blend with base image -> render. This seems to occur even without changing the image source, but it is necessary to change the scale of the Transform2DEffect without disposing and re-creating the effect for it to happen.

I did eventually find an acceptable but inconvenient workaround, which is to add an effect before the transform effect. However, this effect cannot be bypassed due to being the identity, therefore I had to create my own identity pixel shader effect in order for this to work (and thanks for including the PixelShaderEffect in Win2D by the way, with instructions on how to compile the shader - it's really great). So it seems like perhaps the transform/tile effect is copying pixels from a surface that it expects to be filled from the CanvasVirtualBitmap but for some reason these pixels are not filled in (and are just garbage/whatever was there before) unless I add an effect before the transform effect which forces the pixels to be produced from the CanvasVirtualBitmap. This only happens with PNGs, not JPEGs. I don't know if it happens with other image types. It's also possible to workaround using CanvasBitmap instead, but the performance of CanvasVirtualBitmap  can actually be much better and supports very large images.

Please can you pass this issue on to the D2D team? I think it's important to fix this given how important the PNG image format is. I might be able to produce a minimal repro if required, depending on how much time I have available.
 Comments: 
 Comment 0: Thanks, I will pass this along.
 Comment 1: I wonder if you could share a repro of this issue? If so that would be very helpful.
 Comment 2: @MilesCohen-MS - I had a hard time reproducing it as convincingly as in the above picture, but I did eventually get it to happen. Attached is a sample project. Run the project and adjust the bottom slider so the image just fits in the window. Then move the top slider around to adjust the texture size (don't make it too small else it will be very inefficient since I haven't enabled CacheOutput). I found that between scale 1.01 and 1.1 (approx), I got a rectangle artefact in the top right of the image. To test with another image, click the 'Switch background' button, then I get an artefact in the bottom left under the same conditions. It's strange that I wasn't able to get so many artefacts as before though.

[VirtualBitmapRenderTest2.zip](https://github.com/microsoft/Win2D/files/5709356/VirtualBitmapRenderTest2.zip)

 Comment 3: Thanks for the repro. I can confirm that you are hitting a bug in Direct2D here, caused by a faulty optimization of this effect graph. It sounds like you have a workaround here already, but for what it's worth I also noticed that if you set the BorderMode to Soft on the textureScale effect (the first effect applied to the texture), then the bug no longer repros.
 Comment 4: Thanks for looking into this. Any idea which OS version it will be fixed in? I'll try to remember to check if the original bug is fixed once this OS version is released as a stable version (although I will have to remove my workaround to check it, which may or may not be practical).
 Comment 5: Unfortunately, I'm not sure when/if this one will be fixed.
 Comment 6: Thanks for the reply. 

I can understand that this might not be a priority, but it would be quite disappointing if it wasn't fixed. If it's a faulty optimization of the effect graph presumably there are other situations in which it could apply. I could understand not fixing it if the API was deprecated or likely to be replaced soon, but as far as I am aware Direct2D is still the foundation of Windows graphics and is supposed to be a solid foundation to build on, so I would think that any bugs in Direct2D ought to be fixed. I suppose maybe there is a concern of introducing another regression with the fix, but in my opinion this just means being extra careful.

At the very least, if bugs like this aren't going to be fixed, they should be documented somewhere so that developers can work around them without wasting a lot of time diagnosing them.
{'source': 'GithubIssues', 'repo_name_with_owner': 'microsoft/Win2D', 'issue_id': 705564879, 'repo_stars': 522.0}