Harden config import against malicious payloads

[ethicnology]

Importing an Obtainium backup (file) or config link (obtainium://app/…)
applied the payload with almost no validation:

1. Arbitrary settings write: every key in the imported settings object
   was written verbatim to SharedPreferences — including
   externalInstallerPackage/externalInstallerComponent (which would
   redirect all future installs to an attacker-chosen app) and -creds
   keys (overwriting stored tokens).
2. Silent overwrite: an imported app whose id matches an existing one
   replaced it — including its source URL — with no notice. A shared
   "add this app" link could quietly repoint a trusted app to a malicious
   source, making the next "update" serve attacker content.
3. No ReDoS guard: user-supplied regexes (versionExtractionRegEx,
   apkFilterRegEx, customLinkFilterRegex) from an imported config run
   on every update check; a catastrophic-backtracking pattern hangs them.

What this PR changes

Suggested reading order — each commit stands alone:

1. fix: only import allowlisted settings keys from backups — imported
   settings are applied only if they are in an explicit allowlist of
   user-facing preferences. Credentials, the external installer identity,
   device-specific state (exportDir) and onboarding flags are ignored
   (and logged).
2. fix: tolerate map-shaped additionalSettings in app import —
   robustness: App.fromJson and the JSON migrations now accept
   additionalSettings both as a JSON-encoded string (export format) and
   as an already-decoded map (hand-crafted or third-party payloads),
   instead of failing the whole import.
3. feat: warn about overwrites and insecure settings before importing —
   both import paths (file picker and obtainium:// deep links) now show a
   blocking warning dialog when the payload would overwrite an existing app
   (showing the URL change), uses a cleartext http:// URL, enables
   allowInsecure, or contains a potentially unsafe regex. The user can
   cancel or proceed.
4. fix: strip potentially unsafe regexes from imported configs —
   regex values that fail a best-effort safety check (compilation + timing
   against short adversarial probes) are removed from imported apps and
   logged, so a malicious config can't hang update checks.

What it deliberately does NOT change

• Legitimate backups round-trip unchanged: all user-facing settings remain
  importable, and clean configs produce no warnings.
• No changes to the export format, no new settings, no behavior change for
  manually-added apps. New UI strings are en.json only (other locales via
  the usual translation process).

[ImranR98]

Thanks for the PR. Not sure a whitelist is a good idea since we have to remember to maintain it and keep it in sync with new items. Also items not in the whitelist are dropped quietly so that would add to the confusion if the list is not maintained. Instead of this approach, maybe we should have a detailed confirmation dialog that lists out all settings that are about to be imported, with a checkbox for the user to manually opt out? Maybe high risk items like externalInstallerPackage could be pinned to the top of the list so the user can't miss it.