Fix combinedAppSpecificSettingFormItems mutating shared form item state

[RJNY]

Discovered during an investigation: RJNY/Obtainium-Emulation-Pack#104

There are two bugs, both related to how Obtainium manages per-app settings.

The first is that the code responsible for building each app's settings screen modifies shared data in place instead of working on a copy, so settings from one app source can bleed into another.

The fixe is straightforward, the settings builder now works on a copy of the data instead of the original.

---

second "bug fix" was removed. keeping below for posterity.

The second is when Obtainium can't match an app's version string against a narrow set of recognized formats, it silently turns off version detection and saves the change to disk. This runs on every app load, so even if a user manually re-enables it, it gets switched off again immediately.

instead of disabling version detection when formats don't match, the app falls back to a simpler comparison that just checks if the two version strings are identical. This is the same approach Obtainium already uses for 9 other app sources like F-Droid and APKPure

Note that apps already affected will need version detection manually re-enabled after updating.

[ImranR98]

The second issue is not a bug. Those 9 sources are guaranteed to always provide real version numbers, so we don't need to worry about complicated comparisons and format checking. For other sources, like GitHub or HTML, a "version" provided by the site could be any arbitrary string, totally unrelated to the real OS-provided version number.
Version detection related code in general was tricky to figure out due to the huge number of possibilities and edge cases (there are various issues you can search up to see the history) so I would be very cautious of changing it.

[RJNY]

Fair enough, I dropped that "fix". Thanks for explaining, good to know the intent behind it.

I think the reason this keeps getting raised as a bug is because the toggle is silently mutated rather than visibly disabling itself with an explanation. Users see a setting they turned on just turn off with no context, so they assume something is broken. A disabled toggle with a short explanation would probably cut down on repeated reports.

[RJNY]

did a small little refactor since this was back on my radar, should be good to review