Design interaction between scopes and SSO logins

OAuth2 logins require a redirect URL configured on the OAuth provider (i.e. Salsa in our current case), and switching to scopes in URLs, OAuth2 endpoints are now resolved by default using the debusine scope.

This needs some redesign, and I can see two options:

1. Move OAuth endpoints outside the scoped URL namespace. Pro: configured OAuth2 providers are enabled for all scopes; Con: we need to code a way to redirect to the intended scope after login
2. Keep OAuth scope-specific. Pro: one can configure different OAuth2 providers for each scope; Con: one has to configure OAuth2 providers for each scope

Besides these pros and cons, the question here is whether a debusine instance should share OAuth2 configuration between all scopes, or whether we envision a hosting system where different scopes use different external ID providers

Plan for this:

• Moving SSO endpoints out of scope: #583 (closed) (now missing only !1429 (merged))
• Adding salsa accounts to a Debian group can already be done with !1339 (merged)
• Define what roles and permissions the Debian group should have