Use `StagingBelt` for uploading data

[hecrj]

Instead of reallocating staging buffers every frame, we ask the user to provide a staging belt of buffers.

@rukai @dhardy Does this seem like a good idea to you?

[rukai]

I have never used the staging belt myself and the extra boilerplate needed to use wgpu_glyph didn't look very appealing. So I asked cwfitzgerald what he thought about it and he said:

[cwfitzgerald]

To add on to that, when I ported imgui-wgpu over to 0.6, I used write_buffer and was able to keep the api consistent with the middleware pattern. I need to do proper benches comparing write_buffer with a staging belt at some point, but I'm not sure exactly how to properly bench it.

[hecrj]

The StagingBelt is replacing a bunch of Device::create_buffer_init and CommandEncoder::copy_buffer_to_buffer.

We cannot easily use Queue::write_buffer because glyph-brush forces us to couple both buffer preparation and drawing (the caching strategy can overwrite old glyphs). In other words, if a user wants to draw two different layers of text in the same submission, we need different buffers for each layer. Therefore, we need composability at the CommandEncoder level.

I will remove the layer limitation eventually, but it is not the point of this PR.

[dhardy]

The glyph-brush caching strategy doesn't precisely meet kas-text's needs: for that, ahead-of-time buffer preparation would be possible (although it would require a few changes). Probably for any application, clearing of unused glyphs could be demoted to an infrequent garbage-collection cycle (or disabled entirely — e.g. many games will have a hard limit on the number of glyphs they actually draw).

Regarding the specifics of how to copy data to GPU memory I'm the wrong person to ask.

[cwfitzgerald]

Oh I see the problem, that's a tough one.

Given those constraints, I think this is reasonable until that constraint can be lifted.