Changing your password with an access token asks to verify your email address even if you have never added one

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

---

### Description

When querying [POST /_matrix/client/r0/account/password](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-account-password), Synapse will check whether you've provided an optional access token. If you haven't, UIA will be engaged with an `m.login.email.identity` entry. This happens irregardless of whether the account has an email associated with it or not.

https://github.com/matrix-org/synapse/blob/177dae270420ee4b4c8fa5e2c74c5081d98da320/synapse/rest/client/v2_alpha/account.py#L159-L225

If you do provide an access token, then UIA is still engaged, but this time using the UIA flows that make sense for your account (for instance, if you need to verify via SSO).

All of this makes sense when you think about how Element is set up. If you're logged in, an access token will be provided when you try to change your password. Or, if you're not logged in (and don't have an access token), you'll be trying to reset your password using an email address. But this can be a bit confusing for a new client developer who's just reading the spec for the above endpoint. In fact this confusion originally came up [while writing Complement tests](https://github.com/matrix-org/complement/pull/117/files#r639021836).

I'm not entirely sure whether this is a problem with the protocol or Synapse. But client devs, seeing from the spec that this endpoint provides UIA, will try to complete an `m.login.password` flow without providing an access token. And they'll fail UIA as only `m.login.email.identity` is allowed if you haven't provided an access token:

https://github.com/matrix-org/synapse/blob/177dae270420ee4b4c8fa5e2c74c5081d98da320/synapse/rest/client/v2_alpha/account.py#L219-L226

I think we should either:

1. Accept `m.login.password` and other flows if an access_token isn't provided (though I'm not sure if this would work with SSO users etc.)
1. Keep Synapse's logic and be clearer in the spec that if an `access_token` is not provided in the request, only proving your identity via 3PID validation is allowed (but again, I'm not sure if this is really a requirement or just something we've implemented in Synapse based on assumptions).