This PR removes the restrictions of having one Auth provider per URL, and instead allows one auth provider for each URL+ClientID combination.

The URL restriction came from the way our old permissions table worked, but with the user_repo_permissions table, this restriction no longer applies as permissions are stored against individual external accounts.

This has also become an increasingly common ask from customers, and it also eases the transitioning when switching from one auth provider to another, like switching from traditional GitHub OAuth to GitHub App Oauth.

One caveat that remains: Having multiple auth providers for the same URL does not play well with repo-centric permissions syncing, as we cannot from the repo token's perspective determine which user external account a permission should be bound to. There isn't a clean workaround to make this work, and the suggestion is to turn off repo-centric permissions syncing when using multiple auth providers to the same URL.

The idea is to have a follow-up PR that allows us to disable repo-centric permissions syncs for individual code host connections.

Having two auth providers and account connections that both point to github.com:

Some follow-up tasks:

• Change this code so that auth providers are grouped by UniqueID and not ServiceID
  • This will require changes to each individual auth provider. But it would allow us to not sync permissions using an external account that no longer has an active auth provider.
• Allow users to delete external accounts that are no longer associated with a valid auth provider
• Add a code host connection option that allows disabling repo-permissions syncing on a code host connection level

Test plan

Lots of tests updated and adjusted to fit the new criteria.