Allow the Admin API to create a user where the same localpart exists with uppercase letters

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

---

# Description

Note, I have added a space after the @ in all example Matrix IDs in this issue, this is to avoid pinging the existing @ Alice user on GitHub.

## Use case

There are a handful of users who have uppercase letters in their Matrix ID from before Synapse started enforcing lowercase only. They may want to create a new Matrix account with a spec compliant all lowercase localpart.
Ie. they currently have @ Alice:example.com, but want to register @ alice:example.com

## Proposed solution

Adding a feature to the [User creation Admin API](https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#create-or-modify-account) to allow registering @ alice:example.com when @ Alice:example.com already exists.

Authentication endpoints may also need updating when implementing this as these may ignore casing currently.

## Security considerations

The localpart availability checker and both client-server and Admin user creation API endpoints ignore casing today and should continue doing this by default.

- This is to avoid impersonation by allowing client-server API registrations of the lowercase version of an existing MXID with uppercase letters. It is expected that server administrators have verified the users identity before registering this new lowercase Matrix user for them.
- Also to avoid changing the behavior of existing Synapse user management portals that rely on Synapse for localpart validation.

We should add a parameter to the API something along the lines of `&ignore_localpart_casing_duplicates=true`. This need to be an optional parameter and default to `false` if not set

Start with the User creation Admin API documentation linked in the issue, then trace the Admin and client-server user creation endpoints and the authentication endpoints that may ignore casing. Done means an optional ignore_localpart_casing_duplicates parameter permits the Admin API case while default localpart checks and client-server registration remain case-insensitive.

Written by the indexing model from the issue text.