Add warning about known problems when configuring use_frozen_dicts

[MadLittleMods]

Add warning about known problems when configuring use_frozen_dicts

As a follow-up, we should consider removing this config option altogether. It's "expensive" and claims to "prevent bugs" but actually introduces a whole new class of bugs. It could be re-introduced with a more holistic solution to the typing. Or a completely new approach (safe mode that blows up when someone mutates the event content, always make deep clones when handing out references, etc)

Dev notes

The use_frozen_dict config option was there since inception but was only recently documented for completeness sake.

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)

[MadLittleMods]

This is the same warning format as other places (we're not that consistent though)

synapse/schema/synapse-config.schema.yaml

Lines 3084 to 3086 in a9361c4

	> ⚠️ **Warning** – The additional consequences of replacing
	[`macaroon_secret_key`](#macaroon_secret_key) will apply in case it
	delegates to `registration_shared_secret`.

synapse/schema/synapse-config.schema.yaml

Lines 3682 to 3686 in a9361c4

	> ⚠️ **Warning** – Replacing an existing `macaroon_secret_key` with a new
	one will lead to invalidation of access tokens for all guest users. It
	will also break unsubscribe links in emails sent before the change. An
	unlucky user might encounter a broken SSO login flow and would have to
	start again.

[frebib]

If this implementation is buggy, wouldn't it just be better to remove it, or at least disabled it unconditionally until it works? Seems ill advised to me to leave options in that actively break software

[MadLittleMods]

Agreed 👍 PR description suggests a follow-up to remove.

I'd rather document this now than be held up by a refactor that may never happen or is a more controversial change in terms of getting it across the line. It also makes the follow-up PR more clear as the reasoning is contained within.

[MadLittleMods]

Thanks for the review @frebib and @erikjohnston 🐬