… users, and token credentials (wouterj)

This PR was squashed before being merged into the 5.4 branch.

Discussion
----------

[Security] Deprecate AnonymousToken, non-UserInterface users, and token credentials

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | yes
| Tickets       | Ref #41613, #34909
| License       | MIT
| Doc PR        | -

This is a continuation of `@xabbuh`'s experiment in #34909 and `@chalasr`'s work in #42050. This hopefully is the last cleanup of `TokenInterface`:

* As tokens now always represent an authenticated user (and no longer e.g. the "username" input of the form), we can finally remove the weird `string|\Stringable` union from `Token::getUser()` and other helper methods and require a user to be an instance of `UserInterface`.
* For the same reason, we can also deprecate token credentials. I didn't deprecate `Token::eraseCredentials()` as this is still used to remove credentials from `UserInterface`.
* Meanwhile, this also deprecated the `AnonymousToken`, which we forgot in 5.3. This token is not used anymore in the new system (anonymous does no longer exists). This was also the only token in core that didn't fulfill the `UserInterface` requirement for authenticated tokens.

Commits
-------

44b843a [Security] Deprecate AnonymousToken, non-UserInterface users, and token credentials

…ot an AbstractToken (chalasr)

This PR was merged into the 5.4 branch.

Discussion
----------

[Security] Do not deauthenticate token on user change if not an AbstractToken

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

In #42050, we moved the `hasUserChanged()` logic used for deauthentication from AbstractToken to ContextListener.
Problem is that this check is now done against on all kind of tokens, whereas it was only for `AbstractToken` instances before.
That breaks https://github.com/scheb/2fa, tokens get wrongly deauthenticated in the middle of the 2fa auth process.
This fixes it by skipping non-AbstractToken implementations.
We may want to provide a way to opt-in/out the `hasUserChanged()` logic on a custom token with e.g.  a marker interface, but that's not necessarily worth it for now IMHO.

Commits
-------

fe31fcb [Security] Do not deauthenticate token on user change if not an AbstractToken