Consider how the current `Authentication` is merged with additional `Authentication` instances

[rwinch]

CAUTION This is a ticket that needs to be considered by the Spring Security team and thus is not currently a candidate for a pull request.

Currently the behavior for merging Authentication is to add the authorities of the existing Authentication to the new Authentication. We should carefully consider if this should be inverted. Upon deciding, we should document the way in which it is performed and the reasoning for that.

NOTE: If gh-17987 is implemented, users could invert the behavior by returning a custom Authentication.toBuilder() implementation.

[jzheaux]

Two things come to mind as I consider this. One is that if there is a reasonable way to make this configurable, that's a nice escape hatch.

The second is that it I intuit that the most recent authentication is the most trusted one. This seems like the most reasonable default since, if needed, the second authentication has the option of re-looking up anything that the first authentication has and applying it during the authentication process. For example, it can re-query the database for the UserDetails instance.

If we are instead able to hand the entire previous authentication, I also wonder if this becomes a moot point. This could be done either with an .authentication method in the builder like #17987 talks about or it could be addressed as a strategy that takes both authentications and returns an authentication.