Fix bugs in ScummVM launch script

[ctrueden]

As discussed at:
https://retropie.org.uk/forum/topic/29349

[cmitu]

For users that already have the .svm files in place (game.svm), maybe it would be better to skip the creation of a new entry.
They may have scraped already the games and have the gamelist entry present, this would double their gamelist entries.

[Gemba]

FWIW, the thread was split and is now https://retropie.org.uk/forum/topic/32058/scummvm-launcher-improvements

[ctrueden]

Thanks @Gemba. I didn't realize this was being discussed so actively lately. I've been meaning to circle back around to this PR; I'll try to catch up on the forum first before I push anything new.

[ctrueden]

Reading over the forum topic, this is a bigger can of worms than I realized. I don't think I'm going to have enough time any time soon to think more carefully about this problem—especially the dichotomy between the two ScummVM flavors.

Off the top of my head, my instinct for solving that issue would be first figure out how to discern which of the two flavors of ScummVM is in use within that installation, and then have the behavior of the shell script contingent on that information. Of course, one must still make decisions about how aggressively to generate .svm files. Best is probably to add some flags to the top of the shell script letting people control this, and then in the documentation on the website explain how to configure these things, so that everyone can decide for themselves how they want it to work. Finally, for default behavior, I think it should come as close as possible to "just working" out of the box as possible, which to me means trying to stay in sync with the ScummVM UI, i.e. autogenerating .svm files always to match what the UI has configured. To accommodate manually created or tuned .svm files, there could be a comment in the file indicating it was autogenerated, which users can remove if they want that .svm to become "sticky" i.e. not get deleted by the auto-syncing logic.

I'll leave this PR open as is, in case anyone else has time to work further on this.