* Add matrix_bridges_msc4190_enabled flag for using msc4190 on supported mautrix bridges.

* Apply to_json to msc4190 in mautrix configs

* Add | to_json to mautrix bridge registration io.element.msc4190.

* require matrix_synapse_experimental_features_msc3202_device_masquerading_enabled for matrix_bridges_msc4190_enabled

* Also add msc4190 support for mautrix-telegram

Now that https://github.com/element-hq/element-web/pull/29471
is part of v1.11.96, we don't need to carry around this custom workaround.

This also reverts e5574a405e because:
- it was causing issues on some servers (not clear why)
- such workarounds are no longer necessary when doing multi-stage building.

This is a security patch for Synapse that fixes an actively exploited bug.

Various old guides mention this, but it seems like neither Element Web,
nor Element Desktop make use of it.

Element Web & Element Desktop use their own `config.json` configuration to figure out where
Element Call is.

Some Element Call setup resources say that `/.well-known/element/element.json` should be served on the base domain
and should contain content like this:

```json
{
	"call": {
		"widget_url": "https://call.element.example.com"
	}
}
```

We were already generating the file via `matrix-static-files`, but weren't serving it yet.

This patch makes sure it's served on the `matrix.` domain, which allows
people to set up serving on the base domain via a redirect or reverse-proxying.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562