Improve remote configuration for Service URL overrides

[pyby]

Description

The previous implementation in #538 was an urgent fix, but the service URL override mechanism was not optimal.

This PR refines the approach by introducing a structured remote configuration property that allows each service (environment) to have its own substitution URL.

Changes Made

• Removed serviceURL remote configuration property as a string.
• Introduced serviceURLs remote configuration property, a JSON dictionary where service IDs act as keys and corresponding URLs as values (similar to optional playURLs remote configuration property).
• Removed default local configurations.

How to test

1. Add in a local ApplicationConfiguration.json:

 "serviceURLs":
  "{\"production\":\"https://il.srf.ch\"}",

2. Rebuild the app.

The production server should now use this base url.

Checklist

• I have followed the project's style guidelines.
• I have performed a self-review of my own changes.
• I have made corresponding changes to the documentation.
• My changes do not generate new warnings.
• I have tested my changes and I am confident that it works as expected and doesn't introduce any known regressions.
• I have reviewed the contribution guidelines.

[waliid]

For the ServiceObjC, we still have ids, which could lead to confusion. Here is a patch. I may have gone a bit too far, so feel free to keep only the necessary changes.

[pyby]

@waliid I reviewed your patch. ServiceObjC.environments was in my thinking part as well.
Few missing updates in SettingsView.swift and make check-quality failed, so a apply it myself and try to add you as co-author :)

[defagos]

I see that @waliid already reviewed the code, I therefore won't delve into the actual implementation itself.

Still, as I was asked for a review, I would question the need for such a configuration mechanism in the first place. What happened last week was something totally unexpected (and which should never have occurred in the first place), but we cannot have code to deal with any kind of potential failure our products could face. Otherwise we would also need to have a local copy of the metadata database in case someone drops the database, which should never occur in practice. IMHO we have to identify where safety nets must be meaningfully introduced, but not introduce them for the sake of having a safety net for each kind of potential failure.

For this reason, instead of improving what was added in #538, I would rather suggest reverting #538 now that the problem is over. If you think this mechanism is really needed, I would also suggest you align with other platforms so that the desired feature can be enabled everywhere consistently.

[pyby]

I got first a mixed status of rollback or improve it as well.

Why trying to improve it after discussions:

• Play SRG web deployed a service host name update in less than 1 hour, not native mobile apps.
• SRF native mobile apps have this remote option in Firebase (shared by @NicolasBrunnerSRF).
• Play Suisse mobile applications have this remote option in a custom remote configuration system (shared by @SebastienChauvin).