Disabling SAML/JWT Locks out Previously Provisioned SSO Users - Offer a way to re-enable them

Changing this from bug to a feature request

The issue is the same as this one [https://github.com/metabase/metabase/issues/46634](https://github.com/metabase/metabase/issues/46634) ... Seems only Google SSO was fixed since there is no requirement that IdPs using JWT or SAML are sending us real emails or emails owned by the user authenticated by the IdP with them (unlike google sso), so turning off SAML/JWT could inadvertently allow totally unknown third parties to reset passwords and access an instance.

### To Reproduce

1. Set up SAML such that users are provisioned when the account is created
2. Log in as a user
3. Enabled password auth on the instance and disable SAML
4. Try to initiate a pw reset for the provisioned user
5. See that the email indicates that the user should contact the admin for help setting a password

```
We can't reset your password because you're using single sign-on to log in to Metabase. Use the "Sign in with SSO" button on the log in page. To change your password, you'll need to contact an administrator.
```

**Describe the solution you'd like**
A way for Admin via the UI to reset the user `sso_source` so they can reset their password. Something like this:

**Describe alternatives you've considered**

The only workaround after this is to access the `core_user` table and make sure that the users that logged with SAML have the `sso_source` is set to null

ltril

Start with the admin UI and password-reset flow described in the issue, then trace how the core_user table's sso_source affects provisioned users. Review the related issue #46634 for context; done means an administrator can safely re-enable password reset for a provisioned SAML/JWT user without allowing unintended access.

Written by the indexing model from the issue text.