Using a config.json file to manage remotely feature flags in the mobile client

Hi, we would like to set up a config.json file to handle mobile client configuration (like this is described [here](https://github.com/matrix-org/synapse/issues/9178#issuecomment-767448267).

This is not related to a server, but to a client. We want to define this file for Element Mobile app, then customized clients should be able to define/manage their own file.

The plan is to have a way to disable/adjust a feature implemented in the published clients. For example, we may want to be able to define remotely the best mode of pre-sharing to apply. Another use case would be to handle the client versioning (to announce/force an update).

About backward compatibility, the client will ignore any unknown inputs or empty config file. The only thing that we don't want to have to change is the endpoint hardcoded into the client.

Potential questions on this topic:
- how often might we be refreshing from the client to get an updated config?
the plan is to let the client developers decide, I think the config will be checked when the app is resume

- should we define a unified endpoint, or one by platform?
After thinking, we agreed to go for a unique endpoint. For example: https://config.element.io/client/config.json for Element
Having a unified endpoint will allow us to have a common config:
```
{
"common": { // Type "AppConfig"
},
"ios": { // Type "AppConfig"
},
....
}
````
iOS config will override `common`.
`AppConfig` type is TBD :)

- is it optional?
yes, this URL should be optional in the app settings.

- which file MIME type?
the MIME type would be `text/plain`.

No implementation files, tests, or entry points are named. Start by resolving the TBD AppConfig schema and the behavior for the unified optional endpoint, platform overrides, refresh timing, MIME type, and version updates. Done means published mobile clients can safely ignore unknown or empty configs and apply the agreed remote flags without changing the hardcoded endpoint.

Written by the indexing model from the issue text.