This removes the "FSops" naming scheme, which was meant to mirror the
"RWops" naming scheme, which was also recently removed from SDL3.
The build system defines (`SDL_FSOPS_POSIX`, etc) and the source code
filenames retain this, because there's already things using the word
"filesystem" that might overlap (for example, lots of things have a
unique "SDL_sysfilesystem.c", to query base dirs, etc, but almost
everything uses the POSIX "SDL_sysfsops.c" source code.
Fixes#9288.
If someone needs to, say, include an SDL_Storage object, they can simply point userdata at a structure that includes the the storage and any other data needed in enumeration.
Pass the Wayland window export string in the form "wayland:<handle string>" or the X11 window XID in the form "x11:<XID in hex>" to the file dialog portal, so that the window manager can associate the dialog with the parent window and position it correctly.
Add the xdg-foreign-unstable-v2 protocol and use it to create export handles for toplevel windows, which will be used when an external component, such as the file chooser portal, requires it.
When initializing SDL with the flag SDL_INIT_AUDIO or SDL_INIT_SENSOR the event subsystem also gets initialized(SDL_INIT_EVENTS). This isn't mentioned in the comments.
This commit adds these two comments.
- SDL_RWops is now an opaque struct.
- SDL_AllocRW is gone. If an app is creating a custom RWops, they pass the
function pointers to SDL_CreateRW(), which are stored internally.
- SDL_RWclose is gone, there is only SDL_DestroyRW(), which calls the
implementation's `->close` method before freeing other things.
- There is only one path to create and use RWops now, so we don't have to
worry about whether `->close` will call SDL_DestroyRW, or if this will
risk any Properties not being released, etc.
- SDL_RWFrom* still works as expected, for getting a RWops without having
to supply your own implementation. Objects from these functions are also
destroyed with SDL_DestroyRW.
- Lots of other cleanup and SDL3ization of the library code.
The CRC is used to distinguish between different controllers that have the same VID/PID, so if the CRC doesn't match, it's probably a different controller that we don't know about.
Fixes https://github.com/libsdl-org/SDL/issues/9265