[*] Drop MSVC support

To keep this PR description as short as possible, I will save the
ranting about MSVC for the blog post. In short: MSVC has been nothing
but a complete and utter slog to maintain for the *entire* existence of
Eden. CI is an absolute nightmare, it requires *completely* different
compile flags and definitions, has several sets of hacks dedicated to
getting its codegen to cooperate, is a horror story with respect to
dependency management, and is now completely broken and can't launch
games anymore.

Microsoft, you have long overstayed your welcome. And you're not getting
it back ever again. Good riddance.

Signed-off-by: crueter <crueter@eden-emu.dev>

docs/Debug.md

@@ -9,6 +9,7 @@ When reporting issues or finding bugs, we often need backtraces, debug logs, or
 If your bug is related to a graphical issue--e.g. mismatched colors, vertex explosions, flickering, etc.--then you are required to include graphical debugging logs in your issue reports.
 
 Graphics Debugging is found in General -> Debug on desktop, and Advanced Settings -> Debug on Android. Android users are all set; however, desktop users may need to install the Vulkan Validation Layers:
+
 - Windows: Install the [Vulkan SDK](https://vulkan.lunarg.com/sdk/home)
 - Linux, BSD, etc: Install `vulkan-validation-layers`, `vulkan-layers`, or similar from your package manager. It should be located in e.g. `/usr/lib64/libVkLayer_khronos_validation.so`
 
@@ -30,15 +31,17 @@ Ignoring SIGSEGV when debugging in host:
 ### gdb
 
 You must have GDB installed for aarch64 to debug the target. Install it through your package manager, e.g.:
-* On Arch:
-  * `sudo pacman -Syu aarch64-linux-gnu-gdb`
-* On Gentoo:
-  * `sudo emerge --ask crossdev`
-  * `sudo crossdev -t aarch64-unknown-linux-gnu --ex-gdb`
+
+- On Arch:
+  - `sudo pacman -Syu aarch64-linux-gnu-gdb`
+- On Gentoo:
+  - `sudo emerge --ask crossdev`
+  - `sudo crossdev -t aarch64-unknown-linux-gnu --ex-gdb`
 
 Run `./build/bin/eden-cli -c <path to your config file (see logs where you run eden normally to see where it is)> -d -g <path to game>`
 Or `Enable GDB Stub` at General > Debug, then hook up an aarch64-gdb:
-* `target remote localhost:6543`
+
+- `target remote localhost:6543`
 
 Type `c` (for continue) and then if it crashes just do a `bt` (backtrace) and `layout asm`
 
@@ -69,26 +72,27 @@ For more information type `info gdb` and read [the man page](https://man7.org/li
 
 ## Simple checklist for debugging black screens using Renderdoc
 
-Renderdoc is a free, cross platform, multi-graphics API debugger. It is an invaluable tool for diagnosing issues with graphics applications, and includes support for Vulkan. Get it [here](https://renderdoc.org).
+Renderdoc is a free, cross platform, multi-graphics API debugger. It is an invaluable tool for diagnosing issues with graphics applications, and includes support for Vulkan. Get it at [renderdoc.org](https://renderdoc.org).
 
 Before using renderdoc to diagnose issues, it is always good to make sure there are no validation errors. Any errors means the behavior of the application is undefined. That said, renderdoc can help debug validation errors if you do have them.
 
 When debugging a black screen, there are many ways the application could have setup Vulkan wrong.
 Here is a short checklist of items to look at to make sure are appropriate:
-* Draw call counts are correct (aka not zero, or if rendering many triangles, not 3)
-* Vertex buffers are bound
-* vertex attributes are correct - Make sure the size & offset of each attribute matches what should it should be
-* Any bound push constants and descriptors have the right data - including:
-  * Matrices have correct values - double check the model, view, & projection matrices are uploaded correctly
-* Pipeline state is correct
-  * viewport range is correct - x,y are 0,0; width & height are screen dimensions, minDepth is 0, maxDepth is 1, NDCDepthRange is 0,1
-  * Fill mode matches expected - usually solid
-  * Culling mode makes sense - commonly back or none
-  * The winding direction is correct - typically CCW (counter clockwise)
-  * Scissor region is correct - usually same as viewport's x,y,width, &height
-* Blend state is correct
-* Depth state is correct - typically enabled with Function set to Less than or Equal
-* Swapchain images are bound when rendering to the swapchain
-* Image being rendered to is the same as the one being presented when rendering to the swapchain
+
+- Draw call counts are correct (aka not zero, or if rendering many triangles, not 3)
+- Vertex buffers are bound
+- vertex attributes are correct - Make sure the size & offset of each attribute matches what should it should be
+- Any bound push constants and descriptors have the right data - including:
+  - Matrices have correct values - double check the model, view, & projection matrices are uploaded correctly
+- Pipeline state is correct
+  - viewport range is correct - x,y are 0,0; width & height are screen dimensions, minDepth is 0, maxDepth is 1, NDCDepthRange is 0,1
+  - Fill mode matches expected - usually solid
+  - Culling mode makes sense - commonly back or none
+  - The winding direction is correct - typically CCW (counter clockwise)
+  - Scissor region is correct - usually same as viewport's x,y,width, &height
+- Blend state is correct
+- Depth state is correct - typically enabled with Function set to Less than or Equal
+- Swapchain images are bound when rendering to the swapchain
+- Image being rendered to is the same as the one being presented when rendering to the swapchain
 
 Alternatively, a [RenderDoc Extension](https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw) ([Archive](https://web.archive.org/web/20250000000000*/https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw)) exists which automates doing a lot of these manual steps.