Gamepad UI should not automatically enable DXVK on Windows

[vrad-exe]

Currently, running Portal 2 with the -gamepadui parameter will automatically enable DXVK (or "Vulkan mode" as it's often somewhat erroneously called). This kind of makes sense on Linux, so that Steam Deck defaults to using DXVK/Vulkan instead of ToGL/OpenGL. However, on Windows there is usually very little reason to use DXVK due to DirectX being supported natively. In Portal 2's case, there are a couple graphics driver bugs related to projected textures which DXVK can be used to work around, but this also has some negative side effects:

• It causes stuttering for a while as Vulkan shaders are cached. On faster systems this is only minor annoyance, but on slower systems it will make the game unplayably slow. (Ask me how I know.)
• On some graphics drivers it will break borderless window mode, due to these drivers having a "feature" where they automatically convert borderless window Vulkan applications to exclusive fullscreen
• Due to being a translation layer, it also possibly reduces performance or introduces graphical bugs. I've yet to actually see anyone have problems with this, but the possibility is there.

Finally there's the biggest reason which is just the fact that it's unnecessary and confusing to the user. The UI changes caused by this flag (mainly enlarging things) work perfectly fine if you prevent DXVK from running, and users expect the flag called "gamepad UI" to just enable the gamepad UI, not switch the entire graphics backend (kinda). Of course you can just pass the flag -dx9 to negate this, but it shouldn't really be necessary in the first place, this should just not be a thing that happens. Changing this also wouldn't be taking any options away, players who understand what DXVK is and want to use it anyway could still pass -vulkan to enable it manually.

Ideally this should also be changed on Linux for the same reasons of it being unrelated to the flag's main function, but there may be technical reasons related to the Steam Deck for it to be the case on that platform. It's also not as bad on Linux due to there being much more compelling reasons to use DXVK, due to the downsides I listed above either not being present or also existing in the default ToGL.

(See also the corresponding issue for HL2, Portal, and L4D2)