SqlClient should provide better troubleshooting information when using Entra authentication (esp. w.r.t. Azure SQL vCore changes)

### Is your feature request related to a problem? Please describe.

Whenever SqlClient throws a `SqlException` with the message "`Login failed for user ''`" [sic] it should provide additional information in the exception object (and ideally, the message itself) about **who** the "token-identified-principal" is.

Additionally, SqlClient should detect/handle cases where a SqlConnection failed because the Azure SQL instance it was connected to is being reconfigured due to a vCore configuration change - currently using the `Retry...` connection-string parameters doesn't seem to work for me (is it because it actually connects just fine but some post-connection auth process fails?)

### Describe the solution you'd like

* The "`Login failed for user ''.`" message should be improved to include the current Entra auth principal/user/identity name just like how it currently does include the login-name for SQL Authentication errors. At the very least it could include the name (and other user-identifying data, such as the Azure/Entra Managed Identity GUID) in the `SqlException` object or its `.Data` dictionary as it currently does with `HelpLink` and MSSQL Error `Number` and other metadata.
* The `Retry...` connection-string parameters should handle the case when an Azure SQL connection is temporarily broken due to Azure SQL reconfiguration (such as changing the vCore count). According to my data/logs, `SqlConnection` does not attempt to retry the connection in this case.
* Connection errors due to Azure SQL reconfiguration should be correctly reported as such and not as authentication errors.

### Describe alternatives you've considered

I have not be able to think-up any reasonable alternative.

The _unreasonable_ alternative would be to add the necessary data to any thrown `SqlException` in my application code, where-possible; but there's plenty of gotchas and scenarios where, for example, an application logging its own thread-principal or environment-variables to try to find out who-or-whatever the "token-identified-principal" is and that info might end-up being entirely incorrect due to some underdocumented internal feature like auth impersonation.

### Additional context

My logged `_Login failed for user ';` errors (made with help from the Serilog SqlException helper!) contain no useful information to identify whoever the principal is, as far as I can tell:

In my case, when changing the vCores on my Azure SQL database, connection attempts will fail for a period of about 20-30 seconds (as is demonstrated in my logs I can provide on-request). My connection-string has `Retry` parameters that should handle this.

Also, I noticed the StackTrace of the exceptions happens along a call-path including `SqlInternalConnectionTds.LoginNoFailover` and `SqlInternalConnectionTds.AttemptOneLogin` suggesting to me that it isn't even trying any kind of resilience strategy - which suggests SqlClient _can_ handle this situation, but I haven't seen any documentation with instructions for enabling this (despite following [other documented strategies](https://learn.microsoft.com/en-us/azure/azure-sql/database/troubleshoot-common-connectivity-issues?view=azuresql)).