Optimize the deferred command recording path of Metal

[kvark]

We used to focus solely on the immediate recording, with an assumption that moving as much load as possible from the submission into the recording time would allow us to run faster in an ideal application. Unfortunately, there are issue with this - #2232, resulting in the deferred path actually showing better framerate.

There is a few low hanging fruits in there that we need to fix, as well as profile it nicely in general. E.g. the pass vector and command vectors of each pass are not properly recycled, resulting in a lot of heap allocations and moves (on heap resize). We might want to keep them all in the command pool (which doesn't need locking) and re-use from there.

[kvark]

Setting up:

1. Run Dota with gfx-portability using local version of gfx-rs as a cargo patch
2. Add && false somewhere here
3. Take an Instruments profile and see what can be improved

[kvark]

I believe the heap re-allocation is the major source of problems here (in deferred path). Just going straight re-cycling the vectors doesn't actually end up being the best idea, actually. Implementation becomes a bit wonky, and worst-case memory consumption isn't great either.

Instead, I suggest the following scheme:

• have 4 big arrays recorded:
  1. array of render commands (mixed between passes)
  2. compute commands
  3. blit commands
  4. array of passes, each basically specifying the type of a pass and the range of commands (in one of the other arrays).
• make sure that resetting a deferred command buffer still re-uses that storage

With current passes, clearing the main pass vector automatically drops all the command vectors, making them impossible to recycle. With the new structure it becomes much easier.