extended iniSet to support section headers. Fixes some n64 install/launch issues

[dankcushions]

I found some issues with the mupen64plus scripts where it was duplicating options (txHiresEnable was appearing twice), and also that the hotkeys didn't work on first launch with pi4. I tried to solve these in the install scripts, but found fundamental problems caused by mupen64plus use of section headers ([Video-GLideN64], etc) and duplicated option keys (Version = is used several times). The previous iniSet would always append to the end of the file, which could be the wrong section, and it would always match on the first match, which could be in the wrong section.

The previous method of manually adding the section headers as install progresses works to a point, but quickly falls over if you do things out of sequence. Rather than add further complexity to that file, I think having a seperate 'section' argument and supporting logic makes it a little more robust and maintainable.

The feature also removes a bunch of duplicated code in the mupen64plus.sh scripts :)

There's a remaining issue where some stuff in testCompatibility needs to run for pi4 (currently it's skipped) as it has some relevant blacklists and audio tweaks. will save that for another PR.

[joolswills]

If we are to implement section support it would need to handle cases with the same key value in multiple sections. Right now it can't handle that situation so it could be confusing.

At some point I may replace all this code with something a bit smarter, but I'm not sold on this currently sorry.

[joolswills]

I was thinking to review some existing tools. Eg crudini

But this will all have to wait for now due to other priorities.

[dankcushions]

If we are to implement section support it would need to handle cases with the same key value in multiple sections. Right now it can't handle that situation so it could be confusing.

is there an example of that? with mupen64plus it explicitly needs to NOT do that. eg, the Version = line in each section needs to be set separately (most are set to 1, but still), which was one of the issues i created this for - every time you did iniSet "Version" 1 it would set the first Version it could find, which would typically be in the wrong section. If Version isn't set right for the section, mupen64plus will ignore the section and revert to defaults.

maybe there's a way of additionally handling key values in ALL sections with via wildcard argument or something like that.

i don't mind how you want to do it but right now it's blocker for me doing much more with the mupen64plus install script since everything else i want to do needs it (or something like it!). but i'm in no rush - i'll move on to other things :)

[dankcushions]

Fixed bug where it was setting a key/value pair globally when operating in section mode:

pi@retropie:~/RetroPie-Setup/scriptmodules $ cat test.cfg 
[Section1]
foo=bar

[Section2]
foo=bar
pi@retropie:~/RetroPie-Setup/scriptmodules $ iniSet "foo" "bar2" "test.cfg" "[Section2]"
pi@retropie:~/RetroPie-Setup/scriptmodules $ cat test.cfg 
[Section1]
foo=bar

[Section2]
foo=bar2
pi@retropie:~/RetroPie-Setup/scriptmodules $ iniSet "foo" "bar3" "test.cfg" "[Section1]"
pi@retropie:~/RetroPie-Setup/scriptmodules $ cat test.cfg 
[Section1]
foo=bar3

[Section2]
foo=bar2

[quicksilver7837]

Not sure if this is in the scope of your pull request but Battle for Naboo no longer requires LLE and gliden64 can run the game just fine. As this was the last game still on that blacklist, I would think that section can probably be removed from the mupen64plus.sh

[dankcushions]

@quicksilver7837 thanks for that - i did wonder that to but hadn't got around to testing. i plan to review all the blacklisted items to work out what we need for pi4, if any, and also review what works for pi3 + mesa. but yeah, will do that in a later PR :)

[quicksilver7837]

I have done some more testing with the re-sample algorithm and I have found that "src-sinc-fastest" adds an unacceptable amount of audio latency. Setting the re-sample to "trivial" seems to be a much better solution as it gets rid of the audio crackle issue without adding latency.