Fix: Metal MSAA resolve buffer

[Archez]

After implementing the framebuffer copying commands, I noticed that our MSAA resolve pattern for Metal was incorrect.

What we were doing before was ending the render encoder on the source framebuffer, then creating a blit encoder to copy the source buffers texture to the target buffers texture. This works for the case where the target is not the main window framebuffer and we re-draw the texture via ImGui (n64 mode, internal resolution != 1).

But in the case where the target framebuffer is the main window buffer (0), we were using LoadActionLoad to prevent clearing the frame buffer on the frame. However, the blit operation is performed after the main buffer render encoder is created. This means that the "Loaded" texture is actually the previous frames final result. So MSAA on Metal ended up being delayed by 1 frame and would potentially re-draw unwanted pixels.

To correct this, I have switched all the initial load actions to Clear. Then to properly handle the MSAA resolving for the main window buffer, I created a separate code path that is modeled after the framebuffer copy command. We end the render encoder and create the blit encoder on the target buffer instead of the source buffer. Then before we remake the render encoder, at this point we can change the load action to Load so that we retain the texture from the blit.

This ensures we are using the MSAA results for the correct frame without any previous frame re-draw artifacts.