ui: reconsider implicit tenant selection during login

The current behavior of testing the username and password against each active tenant and authenticating with all for which they are valid -- which potentially is only one -- can have somewhat unpredictable or unexpected results, particularly when a user mistakenly uses the wrong credentials on the wrong cluster (which could happen unintentionally and without being noticed if those are auto-filled from a password manager or the hostname or load-balancer has been reconfigured, etc). The lack of visibility into which tenant one ended up connected to, tracked in #109688, compounds this, but the underlying behavior is inherently somewhat hard to predict.

As an alternative, we might consider making explicit which tenant one wishes to login to during the authentication flow, defaulting to just the default server controller's tenant, in much the way sql session authentication works.

The login page could have an optional/expandable additional text entry box for specifying an explicit tenant by name if the cluster has >1 shared service tenant including the system tenant.

We also should potentially remove the assumption that a user has the same name in all tenants. We could imagine that your user in the system tenant has a prefix like "admin-" to avoid accidental auto-fill of your normal creds, or if operators on different teams are granted system tenant users their names might get scoped to their team, etc so we could see a situation where want to switch between `{system, admin-david}` and `{application1, david}`. Perhaps this indicates we should unify the senate drop-down for user/logout in the top versus the virtual cluster/tenant selection drop down, and indeed just have a single account/session menu, where one can switch between, log out of, or login as another user/to another tenant. This menu could then allow switching between different users in the same tenant, as well as different tenants where the username is different, and different tenants where the username is the same (taking the place of the current tenant drop down).

Jira issue: CRDB-31057

Epic CRDB-24590