fix some post-processing issues

[robtfm]

Objective

fix a few post-processing issues

Solution

• fxaa now respects viewport
• tonemapping is only done on the final camera for a given target
• upscaling writes to the input texture (if required) instead of the output texture if the active camera is not the final camera for a given target (stops post-processing and UI from being dropped for cameras that are not last with MSAA targets, or the last effect from being dropped for non-MSAA targets)

should fix #7435 and hopefully fix #5721 (haven't tested that)

[Keelar]

I just tested it and can confirm that this does seem to fix #5721

[robtfm]

i think there's still one issue remaining: if MSAA is enabled, a first camera renders with an odd number of post-process swaps, and then a second camera runs without doing an msaa resolve (which the UI camera doesn't currently, for example), then the last post-process step will be dropped.

in the current core pipeline this will only occur if you're using MSAA and FXAA at the same time, so I don't think it's a big problem.

i think making MSAA a node in its own right instead of part of the 2d/3d main pass would be the best way to fix this. this is useful anyway as some post effects may want to be pre-msaa resolve. but i'll do that in a separate PR.

[IceSentry]

I tested it and can confirm that this fixes the original issue. I haven't tested with an odd number of viewports though.

Code makes sense to me, could extract the final_order to a shared fn, but it's not super important.

[robtfm]

i just realised why i said on #7435 we needed to keep tonemapping on intermediate cameras and reverse-tonemap in the next camera. this pr would cause fxaa to run before tonemapping if it is not on the last camera...

[robtfm]

closing in favour of #7474