Consider using push constants for camera data

[Neo-Zhixing]

Right now the CameraNode passes the ViewProj matrix to the shader by maintaining a uniform buffer that is hardcoded to be binded on layout(set = 0, binding = 0). @cart explained in #1203 that the reason for this is that

RenderPassNodes can have different cameras assigned to each pass. The higher level RenderResourceBindings can
currently be global, from entities, or from assets. None of those categories fits the "per pass" setup very well. And the
current approach let us do the minimal amount of work required to bind the camera.

Given these, would it be a good idea to put the camera data in push constants, now that wgpu-rs has starting to support push constants?

Based on wgpu::Features, wgpu-rs supports push constants on all five native APIS: Vulkan, Metal, DX11, DX12, and OpenGL. But PUSH_CONSTANTS was not supported on web.

Using push constants for camera data addressed the problem mentioned above because push constants are, by its nature, a "per pass" setup.

[cart]

Definitely worth considering! Random thoughts:

• We'd need to sort out how we expose push constants in the renderer apis
• The "camera binding problem" will likely continue to present itself in other situations. Even if we solve cameras with push constants, we'll still want a good answer for uniforms that fall into a similar category
• I'd want to know a bit more about the "uniform emulation" thats done for unsupported platforms (and how it performs relative to managing the buffers ourselves). i expect it to be slower if we're re-copying the data per-pass.

[Neo-Zhixing]

On a second thought, using push constants require that we copy the camera data to the command buffer for every draw call. With a uniform buffer we'll be able to reuse this data every frame. I'm gonna close this for now.