ATProto: add server side OAuth support, authentication only

[snarfed]

In general, we don't plan to let users log into bridged accounts and use them directly. Too much complexity to get both that and bridging right at the same time and not colliding with each other. So, we wouldn't plan to let users fully log into their bridged Bluesky accounts via OAuth.

However, we could maybe support it for authentication only...? We'd be a normal ATProtro OAuth serve, and return the user's DID in sub, etc, but not generate any tokens or allow any API calls. I think we'd do that by supporting the atproto scope but not transition:generic? Not sure.

Background discussion in #1762

[Tamschi]

Is some sort of token not still required to prove DID ownership? It seems to me that otherwise PDS hosts could impersonate the user towards OAuth even if they self-sign their record changes (which if I'm not mistaken is supported and otherwise trustless in ATProto).

[snarfed]

ATProto OAuth clients are expected to resolve the user's DID to a PDS, and then authenticate against that PDS.

The PDS is still trusted somewhat, eg a malicious PDS could auth user A as user B if both users are on that PDS, but I think that's an expected part of the current ATProto trust model.

[Daft-Freak]

I wonder if this would be enough for things like Discord that want to verify you own the account to show it on your profile. (I don't know what Discord is actually doing, I just know that entering my bridged handle results in a server error and entering a regular one opens a login page)