utilize the user configuration directory for configs and savefiles

[Alto1772]

This change is based from the patch in this unofficial AUR package and has been implemented for quite some time now, so the goal of it is to address or introduce some issues or ideas related to installation paths on Linux systems or anything path related.

Some of the few key changes are:

• The Context::GetAppDirectoryPath function now returns the location of the user's application data directory using SDL_GetPrefPath. This means any game configurations or save files will be stored and read from that directory. This can be overridden by the SHIP_HOME environment variable. By default, this function returns ~/.local/share/soh on Linux or %APPDATA%\soh on Windows.
• The Context::GetAppBundlePath (replaced with Context::GetAppInstallationPath) function now hardcodes the installation path utilizing CMAKE_INSTALL_PREFIX instead of the SHIP_BIN_DIR environment variable, by activating NON_PORTABLE in the configure flags. (In the aforementioned AUR package the installation prefix is set to /opt/soh). Also, I've removed the SHIP_BIN_DIR env var as said and done it's only exclusive to Ship. Update: When on Linux and is portable, it now gives the program's path instead, thus SHIP_BIN_DIR is not needed.
• Added Context::LocateFileAcrossAppDirs to search for a given file in the above paths. If the file is not found, it prepends ./ to the file path without checking.

Note that this modifies where application data (typically configuration and save files) is stored. Update: I've added the configure option -DNON_PORTABLE=ON to seperate portability and system-installed Now these files are located in the OS-specific directories mentioned above instead of the current directory where the program is running. When the game launches unless you did move them, it will reset to the original state. Let me know what are other problems arise from this. Additionally you can check for any other potential issues that I haven't looked upon.

[leggettc18]

LUS probably shouldn't be the one doing this searching of directories to begin with, instead of this, LUS should probably just be handed file paths and not be doing any logic, and the implementing application should probably be responsible for searching these directories.

Also, the SHIP_BIN_DIR env variable is specific to Ship of Harkinian. Other games would probably want to use a different env variable. I realize that one was already in the codebase, it probably shouldn't have been.

Part of me feels like it might be a decent idea for LUS to still expose a function like LocateFileAcrossAppDirs for games to use if they want, but another part of me feels like other libraries for searching the common config/data/xdg folders for these files already exists and should be used by the end-user applications if they want that functionality.

[briaguya-ai]

I would want to make sure we test the use case of having multiple versions of ship with different settings. It seems this logic would always load from the user config dir instead of . if one exists, which removes some of the benefits of portability that we currently get by keeping everything in one place.

For example, if I were to have a release build set up and ready to play, then I download a PR build to test, I wouldn't want that PR build to touch my release build's settings

[Alto1772]

Here's my own suggestions:

• If you want to make the program look for data files in current directory, at least I would add a configure option to disable using the preferred user config folder to store configs/saves. SM64EX for example uses the user config directory for any reason.
• For SHIP_BIN_DIR I could move it to SoH and change the AppBundlePath functionality and its function to name something akin to giving the installation path. I have tried applying CMAKE_INSTALL_PATH to that function (as in the AUR package case) and my concern is that using it by default, by means without adding it to configure options, is still #define'd on the install_config.h after configure so that's why I checked to make it sure.

I've always wanted to put this patch in the codebase as this idea was implemented and engraved to the Arch AUR package i mentioned since the package's creation, using patches that adds slight features that can make program's functionality of what an installed package should do. For portability concerns this is a kind of a problem to users who wanted the program to make it portable. But for some users who are willing to install the program like installing a package this is the way I would do. I don't wanna always update the patch in the unofficial package on failed builds because of new code changes.

[briaguya-ai]

maybe a CLI argument for XDG_MODE or something makes sense? then for installed packages the executable could just be a shell script or something and run the binary with that argument, and for every other instance it would still look in .

[github-actions]

⚠️ clang-tidy found issue(s) with the introduced code (1/1)

No clang-tidy warnings found so I assume my comments were addressed

[Spodi]

Seems like the Shipwrigth repo needs an update to build with those changes.