Changed handling of `web_client_location` conflicts with recommended reverse proxy setup

This issue has been migrated from [#14722](https://github.com/matrix-org/synapse/issues/14722).

---

### Description

In #11895 the redirect from `/_matrix/client` to the URL configured in [`web_client_location`](https://github.com/matrix-org/synapse/blob/develop/docs/usage/configuration/config_documentation.md#web_client_location) was moved to `/`.

In order to make this new location effective, the local administrator needs to adjust the [currently recommended proxy setups](https://github.com/matrix-org/synapse/blob/develop/docs/reverse_proxy.md#nginx), since these include only `/_matrix/` and `/_synapse/client/`.

For example, the nginx setup would need to change in a single line:
```patch
< location ~ ^(/_matrix|/_synapse/client) {
> location ~ ^(/_matrix|/_synapse/client|/$) {
```

But the above change can be tricky for many site operators, since the `/` path may conflict with their regular (non-matrix) web services.

I conducted a quick survey of the servers listed at https://joinmatrix.org/ for their usage of the `web_location_location` feature (based on 91 matrix server entries; see the small shell script at the end of this issue):
* 30 servers (`unkown`) do not offer discovery via the `.well-known/matrix/client` endpoint (just ignore them)
* 7 servers (`local`) return a redirect to a relative destination path (probably not related to a Matrix web client)
* 24 servers (`missing`) do not return a redirect (probably this is just a regular web site - not related to Matrix)
* 6 servers (`misleading`) return an absolute redirect to a regular web site (probably not related to Matrix)
* 24 servers refer to a Matrix web client

I understand the results as follows:
* 60% (37 out of 61) servers use the `/` path for non-Matrix content
* 40% (24 out of 61) servers use the `/` path for redirecting to a Matrix web client

From my point of view there are two options for proceeding:
* A) stick to the `/` endpoint and update the reverse proxy documentation for this new path to be handed over to matrix-synapse
* B) switch to a "final" endpoint somewhere below `/_matrix/` (maybe even back to `/_matrix/client`) in order to simplify the setup for site operators, which serve regular content below their configured `base_url`

Personally, I was mislead to using a regular (content) `base_url` for the dozen of Matrix homeservers, I administer. This was based on the neat reverse proxy setup, which clearly separated the Matrix content (`/_matrix/`) from the remaining content. Now I face the option of either changing the `base_url` and re-arrange the proxy setups or just miss out this nice discovery feature. Thus, I would prefer option (B).

---

For reference: I used the following quick approach for testing the Matrix servers published on joinmatrix.org:
```shell
curl -s https://joinmatrix.org/servers.json | jq -r '.[].domain' | grep -F . | while read -r domain; do base_url=$(curl -s --max-time 3 "https://$domain/.well-known/matrix/client" | jq -r '.["m.homeserver"]["base_url"]' 2>/dev/null) || { echo "$domain unknown"; continue; }; if ! printf '%s' "$base_url" | grep -q "^http"; then base_url="https://$base_url"; fi; destination=$(curl -s --include "$base_url/" | fromdos | grep -i "^location:" | cut -f 2 -d ' '); [ -z "$destination" ] && echo "$domain missing" && continue; printf '%s' "$destination" | grep -q "^/" && echo "$domain local" && continue; if curl -s "$destination" | grep -q matrixchat; then echo "$domain $destination"; else echo "$domain misleading"; fi; done
```

### Steps to reproduce

* read https://github.com/matrix-org/synapse/blob/develop/docs/usage/configuration/config_documentation.md#web_client_location
* read https://github.com/matrix-org/synapse/blob/develop/docs/reverse_proxy.md#nginx
* notice the absence of `/` in the reverse proxy configuration

### Homeserver

matrix.org

### Synapse Version

1.74.0

### Installation Method

I don't know

### Database

irrelevant

### Workers

Single process

### Platform

irrelevant

### Configuration

_No response_

### Relevant log output

```shell
irrelevant
```

### Anything else that would be useful to know?

_No response_