Move security note from README into the docs (#19259)

This is a) to simplify the README and b) so that we can easily link to
the security page from e.g. the installation guide.

Follows on from https://github.com/element-hq/synapse/pull/19228

README.rst

@@ -42,61 +42,13 @@ There are three editions of ESS:
 
 The Synapse documentation describes `options for installing Synapse standalone
 <https://element-hq.github.io/synapse/latest/setup/installation.html>`_. See
-below for more useful documenation links.
+below for more useful documentation links.
 
 - `Synapse configuration options <https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html>`_
 - `Synapse configuration for federation <https://element-hq.github.io/synapse/latest/federate.html>`_
 - `Using a reverse proxy with Synapse <https://element-hq.github.io/synapse/latest/reverse_proxy.html>`_
 - `Upgrading Synapse <https://element-hq.github.io/synapse/develop/upgrade.html>`_
 
-Platform dependencies
----------------------
-
-Synapse uses a number of platform dependencies such as Python and PostgreSQL,
-and aims to follow supported upstream versions. See the `deprecation policy
-<https://element-hq.github.io/synapse/latest/deprecation_policy.html>`_ for more
-details.
-
-
-Security note
--------------
-
-Matrix serves raw, user-supplied data in some APIs — specifically the `content
-repository endpoints`_.
-
-.. _content repository endpoints: https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid
-
-Whilst we make a reasonable effort to mitigate against XSS attacks (for
-instance, by using `CSP`_), a Matrix homeserver should not be hosted on a
-domain hosting other web applications. This especially applies to sharing
-the domain with Matrix web clients and other sensitive applications like
-webmail. See
-https://developer.github.com/changes/2014-04-25-user-content-security for more
-information.
-
-.. _CSP: https://github.com/matrix-org/synapse/pull/1021
-
-Ideally, the homeserver should not simply be on a different subdomain, but on
-a completely different `registered domain`_ (also known as top-level site or
-eTLD+1). This is because `some attacks`_ are still possible as long as the two
-applications share the same registered domain.
-
-.. _registered domain: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-2.3
-
-.. _some attacks: https://en.wikipedia.org/wiki/Session_fixation#Attacks_using_cross-subdomain_cookie
-
-To illustrate this with an example, if your Element Web or other sensitive web
-application is hosted on ``A.example1.com``, you should ideally host Synapse on
-``example2.com``. Some amount of protection is offered by hosting on
-``B.example1.com`` instead, so this is also acceptable in some scenarios.
-However, you should *not* host your Synapse on ``A.example1.com``.
-
-Note that all of the above refers exclusively to the domain used in Synapse's
-``public_baseurl`` setting. In particular, it has no bearing on the domain
-mentioned in MXIDs hosted on that server.
-
-Following this advice ensures that even if an XSS is found in Synapse, the
-impact to other applications will be minimal.
 
 🎯 Troubleshooting and support
 ==============================