Add support for GameInput API on Windows

[Nintorch]

Closes godotengine/godot-proposals#8620

This PR enables GameInput API backend for SDL on Windows. I know we have already discussed this API here, but in this PR we don't include GameInput headers/code, GameInput is downloaded with a script here, so it should be okay.

This PR also removes unused backends in Godot (RawInput, WGI). DirectInput is not replaced by GameInput in this PR since it's still used because of the haptics subsystem and #114642 , and XInput is used as a fallback if GameInput is not enabled in the build (if GameInput is enabled, XInput backend is not compiled).

With this PR the detection of my Xbox One controller has changed:

	print(Input.get_connected_joypads())
	for i in Input.get_connected_joypads():
		print(Input.get_joy_name(i), ' ', Input.get_joy_guid(i), ' ', Input.get_joy_info(i))

[0]
Xbox One S Controller 030000005e040000ea02000000006700 { "raw_name": "Xbox One S Controller", "vendor_id": "1118", "product_id": "746" }

Note that the GUID ends with 6700, which means that this API is actually used. See the line 147 of thirdparty\sdl\joystick\gdk\SDL_gameinputjoystick.c:

    elem->guid = SDL_CreateJoystickGUID(bus, vendor, product, version, manufacturer_string, product_string, 'g', 0);

TODO:

• Should we use this API?
• Check if this PR solves the issue of using more than 4 xbox controllers on Windows
• Create an installation script for the API
• Disable XInput, RawInput+WGI joystick backends
• Scons argument
• Still use XInput if GameInput is not enabled from scons
• Patch file for SDL folder
• Remove Input.get_joy_info()["xinput_index"] since XInput is no longer used
• #define HAVE_XINPUT_H 1
• get_deps_folder() in detect.py is no longer needed
• Remove deleted files from the SDL update script

TODO to fix regressions:

• Fix DirectInput mappings compatibility
• Fix controller names compatibility (Should we do it?)
• Make the driver read inputs if the app is unfocused
• Create GameInput haptics backend for SDL I'm not knowledgeable enough in this area to do that :(
• Fallback to DirectInput for non-gamepad devices if both DirectInput joystick and DirectInput haptics backends are used

TODO for separate PRs:

• A PR for SDL with SDL code changes
• Trigger rumble support ( Add support for joypad triggers vibration #116214 )
• Proper motion sensors support for GameInput backend?

[bruvzg]

this PR we technically don't include GameInput headers/code as they are already provided on the CI machines

This won't work, since the official build system won't have them and users making custom builds won't have them.

What can be done is making this optional (with Scons argument) and add download script for the headers, like we do for DX12 stuff (see install_d3d12_sdk_windows.py).

[Nintorch]

This driver broke controller mapping for my DInput controller :( I will work on fixing this issue.

[Nintorch]

I have fixed the mapping issue, but I think this PR would definitely conflict with #114642 , not sure if a controller that was opened with the GameInput driver can be used with DirectInput haptic effects.
Matter of fact, controller hotplugging for DirectInput controllers in GameInput doesn't work if DirectInput is enabled. If it's disabled then everything is okay.

Maybe if we decide to use GameInput instead of DirectInput, I or someone else would have to create an SDL haptic driver for GameInput :(

And also GameInput doesn't support retrieving input from devices if the application is not in focus, unless I can do something with it.

[Nintorch]

Made a PR that may or may not be better than this approach in the short term: #116101

[Nintorch]

GameInput installation script is done and it makes the GCC Windows template compile!