web: New XSRF/CSRF protection: `Sec-Fetch-Site`

Since 2023, major browsers have offered a new protection from XSRF: the Sec-Fetch-Site header. This is much simpler to use than the invasive xsrf_cookies feature currently offered by tornado, while simultaneously offering stronger protection. See golang/go#73626 for an in-depth discussion of this feature. Also see #3226, in which we previously considered (and rejected) XSRF protection based on the SameSite cookie feature instead.

It is possible for applications to use this header today, such as by checking it in the prepare method:

    def prepare(self):
        if (self.request.method not in ("GET", "HEAD", "OPTIONS") and
            "Sec-Fetch-Site" in self.request.headers and
            self.request.headers["Sec-Fetch-Site"] not in ("same-origin", "none")):
            raise HTTPError(403)

We should make this available in Tornado itself so it is more easily usable and can potentially be turned on by default.

Open questions:

• Should it be the default? Probably not immediately but perhaps in Tornado 7.0
• How is it enabled or disabled? A new flag in Application like xsrf_cookies or something else? (Consider that it may need to be overridden on a per handler basis)
• Where does the check live? In web.py like the current one, or somewhere deeper in the HTTP stack? (perhaps a middleware at the HTTPMessageDelegate level?)
• Do we want a fallback like the Origin==Host check proposed in golang/go#73626?

Start by reviewing the existing xsrf_cookies handling in web.py, then compare the Application, per-handler prepare method, and HTTPMessageDelegate entry points mentioned in the issue. The work is complete when the enablement model, default behavior, request-check location, and any Origin fallback are decided and implemented with coverage for the chosen behavior.