x64dbg: Add toggle to attach game process on startup

[sonic2kk]

Addresses part of #947.

Overview

This PR adds an option to checkbox toggle to control a new variable X64DBG_ATTACHONSTARTUP. This controls whether the game EXE is attached to x64dbg on startup, and it is enabled by default.

Implementation

Default Attach Behaviour

It's on by default because this should have been the default behaviour, but it was not due to a bug. winepath -w was returning a lot of spew before the game path, which meant x64dbg could not actually read the standalone game path. This has been fixed by getting tail -n1 of the winepath -w output, and now x64dbg will start with the game process as it should have (and as it may have done previously).

There was another issue with this default process flow, where when x64dbg was closed, the game would start anyway. This has been fixed by doing a check on this new X64DBG_ATTACHONSTARTUP control variable before we launch the game in launchSteamGame. If USE_X64DBG and X64DBG_ATTACHONSTARTUP are both enabled, then we can assume x64dbg will manage the game launch and that we don't need to do it.

New No Attach Feature

Finally, a new flow has been introduced based on discussion in #947, which was the main reason for adding this checkbox. In some cases a user may want to disable this, for example if they're having trouble attaching the right process by default, or if they want to only attach to a certain game process. So we allow the user to disable attaching the game process by default, and allow the game to launch normally, and x64dbg to launch independently. We do this by sleeping, then running x64dbg, and continuing on to launch the game process. We need to sleep otherwise x64dbg will open and for some reason prevent the game from opening.

The sleep value is a magic number, hardcoded to 5 for now, because 1 didn't work and I didn't encounter a case in testing where any value above 5 was required. It worked in all my tests with as low as 2 as well, but I decided to go with 5 to be as generous as possible without introducing too much of a wait. We could introduce an option to adjust this in future if needed, though.

Since on this path the game is launched by STL normally and has to be attached to x64dbg after-the-fact, we don't have to worry about it launching after x64dbg is closed. Likewise, when the game process is attached to x64dbg, closing the program will close the game process. So in every instance, the game processes and x64dbg should now open and close more cleanly.

Future Work

GitHub changed how it renders the releases page a while ago, and this broke MO2 and Vortex. We fixed that (#592), however it seems we missed x64dbg. Since x64dbg doesn't use tags in the same way, we'll need to figure out another way to find and then download the correct release.

---

This PR was tested by me and also tested by the reporter in #947, so it should be ready to merge after some quick code review and langfile updates. This should work for Steam games and Non-Steam Games. As far as I know, this is not applicable for Native Linux games.

[sonic2kk]

Tested with this new option on and x64dbg off, everything works good. When x64dbg is not installed, RUN_X64DBG is set to 0, so there are no worries of any problems when x64dbg is not installed.

Langfiles bumped, shellcheck green, this works in testing, so it should be ready to merge!