Expose maximum_frame_latency from wgpu to Bevy users

[alice-i-cecile]

What problem does this solve or what need does it fill?

gfx-rs/wgpu#4899 exposes control over the maximum number of frames that should be buffered.

As the linked docs explain

What solution would you like?

Bevy should offer users control over this and document that it exists. We should consider whether to leave this as a manual call, a plugin parameter, or a synchronized resource-based setting. I think that runtime changes to this will be extremely rare, so my preference is a plugin parameter with a documented escape hatch to change the value manually.

What alternative(s) have you considered?

When pipelined rendering is disabled, we should consider swapping to 1, or suggesting that users do so. The sequential-CPU-GPU pattern is what we're already doing in that case, so the lower latency might be a good choice.

Additional context

Thanks to @aevyrie for mentioning this. @JMS55 points out that we're currently defaulting to 2.

[Kanabenki]

Some questions regarding that setting:

• This is technically a per window setting since this is exposed by the surface. While I don't see a use case were the user would want that value to vary per-window, for consistency with other settings like the present mode it may make sense for the user-override to be something like a Option<NonZeroU32> on Window/ExtractedWindow?
• Wouldn't keeping 2 as the default even when pipeline rendering is disabled prevent stalling on the cpu side if a frame takes longer than the others on the gpu side? I guess this would need some latency benchmarking to see the actual effect of that change.

[alice-i-cecile]

it may make sense for the user-override to be something like a Option on Window/ExtractedWindow

Agreed. We should avoid creating leaky abstractions without a good reason.

Yeah, I'm leaning towards keeping the default as 2 in all cases, but we can add doc notes once people experiment with values further.