Use the swapchain-preferred texture format by default

[parasyte]

• Fixes Use the preferred texture format for the swap chain #140
• Adds a public method to get the current GPU framebuffer texture format (AKA the render texture format).
• This wasn't as difficult as it seemed; the extra API is used by the examples to get the right texture format instead of being hardcoded.

r? @JMS55

[JMS55]

Just want to check some assumptions:

1. The format you provide your frame in, and the format used to render are different and separately configured right?
2. How does this play out when using render_with() and calling ScalingRenderer manually? I assume by configuring "render_texture_format" to be the swapchain default, which is different from the frame input texture (see 1. above), we're actually configuring the output of ScalingRenderer. So if you wanted to do ScalingRenderer -> Custom -> SwapChain, where Custom doesn't input the swapchain default, you'd want to tell Pixels to use a non-swapchain-default format for output, and then tell Custom to use the swapchain default as output.

You're right this turned out to be pretty simple. But conceptually it's a bit confusing, and I think we need to document more explicitly what each format in PixelsBuilder is used for, and typical scenarios and what you want to set them to, e.g. summarize point 2. above in the docs.

Please let me know if that all made sense, or if I'm thinking of this wrong :).

[parasyte]

1. Yeah, these are configured separately:
   • `PixelsBuilder::texture_format()
   • `PixelsBuidler::render_texture_format()
2. The custom-shader example shows how it can work. The ScalingRenderer still uses the render_texture_format (e.g. BGRA), and as long as you provide a TextureView with the same texture format, it will be none the wiser.

If you have some ideas for how to better document things, I'm definitely open to it.

[JMS55]

On the render_texture_format functions it should probably say that this controls the output of the ScalingRenderer, and on the texture_format functions it should say that it controls the input of the frame from get_frame(). Or maybe they should be renamed to be more descriptive. Once that's done, this patch LGTM 👍.

[parasyte]

I agree there is a good chance that these things result in confusion. Thank you for your suggestions! I'll spend some time today thinking about ways to help clarify what these texture formats are for, and try to illustrate a better mental model for how everything is weaved through the wgpu pipelines.