Clean up is_frustum projection code

[BastiaanOlij]

Cleanup projection code so we don't need our frustum override in the renderer.

As I'm working through a bunch of projection changes I ran into the hacky workarounds we introduced in the renderer around the "Frustum" camera mode. It always irked me that we had to do these things as they didn't make sense.

What I think happened here is that as we migrated code over from Godot 3, we were actually dealing with an issue that we were incorrectly applying projection[3][2] in our unprojection code.

This was never visible because for all projection matrices except the "newly" introduced Frustum mode, and when stereo rendering, projection[3][2] is ALWAYS zero. With frustum mode we have the ugly hacks, for stereo rendering we use full unprojection and skip the faulty code.

I did a bunch of cleanup to ensure both compatibility and RD renderers use the proper unproject formulas for our sky rendering (the only place we applied the hack) and that we properly and consistently use our flip_y settings so we don't have to make weird changes to the projection matrices to make this work.

Could use some help testing this all out to make sure I haven't overlooked a place, but I've tested all different camera modes, checking if the sky still renders properly, making sure reflections of the sky are still correctly oriented, and checking if reflection probes still render properly and all looks good.

[BastiaanOlij]

cc @dsnopek @Calinou

[BastiaanOlij]

One small remark here, and also for the same calculation in the render device version of this shader. We're doing an addition here which is counter intuitive because for un-projecting you would expect to subtract.

But we have to remember that originally we project our vertex by doing + z * projection[2][0] and we are looking in the z- direction. So we end up with + -1.0 * projection[2][0] which means we need to do - -1.0 * projection[2][0] to un-project. Hence + projection[2][0]...

Also very counter intuitive is the order in which we've stored our projection matrix entries into our vector, yes projection.x stores projection[2][0] while projection.y stores projection[0][0].

Just interesting info to have for prosperity :)

[Calinou]

Tested locally on the 3D platformer demo (with camera mode changed to frustum), it works as expected. I double-checked the sky orientation is correct on all renderers.

Code looks good to me.

[Repiteo]

Thanks!