Proposal: Add SDL2 as an applicable backend

[capnkenny]

Priority: Low

Details: As the title suggest, we may want to look into utilizing SDL2 after MVP as another possible backend for NovelRT, akin to how GLFW/OpenAL are backing it today.

Mainly, using SDL2 as a backend would allow for potentially streamlining porting to non-desktop devices and also potentially open up avenues we can explore for implementing other graphics libraries with/without doing explicit development for them.

In the case of more adaptable porting - for example:

• For devices that still support Vulkan, we should be able to utilize SDL2's Vulkan capabilities and reuse most of the existing Vulkan logic we have - SDL2 could fill in for Input, Audio, and Windowing to handle the rest
• If we were to use SDL2 as a backing provider, we can have it do most of the heavy lifting for additional dependencies without us being as responsible for them
• For targets that don't exist (Browser, mobile, UWP) SDL2 already has targets built, therefore leaving us to do less configuration work if we were to want to support that approach (I believe native is best, but I feel that in cases like Browser support, or in areas that may be community supported, this would give more leeway)

In the case of additional graphics libraries:

• SDL_gpu appears to be actively maintained, and provides a way to streamline access to graphics rendering similar to using the SDL Renderer, backed by OpenGL 1-4 or OpenGL ES 1-3.0 (D3D9-11 are provided but without SDL Renderer support, and I doubt we'd want to go that route anyways if we have the ability to call D3D ourselves)
• ^ Using the above, we can also use explicit calls to OGL if we want to manually define a "high-level" pipeline so we don't run into issues like we did prior to Vulkan's implementation
• OR "eventually" there may be the newly proposed SDL GPU API that is being worked on by a prominent contributor to SDL2 (that was said could wrap Metal, DX12, Vulkan, DX11, and OGL4)

In any case, I think there's a multitude of reasons (seeing SDL2's versatility) as to why we might want to implement it as a supported backend. With that said, however, it's certainly up for discussion as to if/why/how we would support it.

Also, very open to outside feedback here if anyone has thoughts! (Is this needed/wanted? Any issues foreseen? etc.)

[RubyNova]

What would the implications of this be on the rendering interfaces and implementations I would have to maintain?

[capnkenny]

That is purely dependent on how far we want to go with the implementation, afaics.

For this instance, as long as no GLFW specific code is in the Graphics.Vulkan namespace, this would just require (in theory) adding a Windowing.SDL variant that can provide whats needed for the window context, and then allowing the default rendering system to pick SDL over GLFW in this case. Maintenance should be lower cost here, however YMMV with the other interfaces since.. they don't exist just yet 😆 (DX12 and Metal are supported though so in theory it's the same cost)

Another instance is implementing a high-level renderer (akin to OGL) - this is clearly much higher cost initially, since it'd require a whole new Graphics subset and RenderingSystem, but I can't speak on maintenance unless we know how we're rendering (letting SDL manage the rendering work vs. writing OpenGL/ES/D3D9-11 code are two completely different strategies and therefore costs)

[SmylEFace]

I can take this one

[YukiiVR]

I'll take it