Componentize OAuth Logic

[germ-mark]

This is the next (last)? macro PR in building this out from OAuthenticator.

Context

So far the code sequence has largely followed OAuthenticator. In previous steps, the project was reorganized to separate out OAuth specific types and logic into the oauth4swift package, and break them free of the entangling with atproto concepts (did, handle resolution) that we introduced.

Prior to this PR, oauth4swift had very little request handling logic, the logic portions of oauth4swift were focused on state management (e.g. lazily calling refresh when making a protected resource call, and serializing those authorization refresh requests). This reflects the legacy of OAuthenticator, where the bulk of the logic is implemented per service, and passed as abstract handlers into the core Authenticator object (https://github.com/ChimeHQ/OAuthenticator/tree/main/Sources/OAuthenticator/Services). This became evident here when a lot of OAuth logic was sitting in AtprotoOAuth and not in the OAuth library. This PR aims to fix that.

OAuthenticator's primary component was the state management in Authenticator, which carries on in oauth4Swift. The motivation for embarking on this reorganization was to collect the service-independent logic as primitive components in the way that oauth4web did.

This pr starts doing so by paralleling the method naming of oauth4web, and shadowing the (mostly) pure functions it defines.

Divergence from oauth4web

• Url construction differs slightly. We favor passing typed structs around such as URLRequest instead of headers, bodies, and parameter dictionaries, so we construct our url requests in a somewhat different order than in oauth4web
• While oauth4web aims to be stateless (e.g. it doesn't handle refresh logic, which we do), DPoP handling undermines that statelessness. Making a dpop request requires getting, setting, and retrying with nonce, which oauth4web does. Rather than injecting an optional DPoP object as OAuthenticator and oauth4web do, I want to encapsulate the read, set, and retry logic of the mutable nonce state within the isolation of where those nonces are stored. Hence we have optional conformance to a DPoPSigner protocol, upon which we conditionally insert a proof.
• There is an OAuthComponents namespace for pure functions, but it's mostly for response handling. Making requests will conditionally need to access mutable state, which means most of them need to be (protocol) methods which can at runtime determine if the object they're attached to is a DPoPSigner

ToDo

• Clean up unused types, commented out code
• Clean up the logic around optionally injecting Dpop proof and retry
• (followup pr) add testing now that the OAuth API is more stable

[ThisIsMissEm]

Quite a lengthy review, I've added some explainers where necessary and raised a few questions.

[ThisIsMissEm]

This is to support OIDC and deployments like keycloak, because .well-known is a well known mess, funnily enough the spec says:

Well-known URIs are rooted in the top of the path's hierarchy; they are not well-known by definition in other parts of the path. For example, "/.well-known/example" is a well-known URI, whereas "/foo/.well-known/example" is not.

And OIDC's like "nah bro, I know better":

[...] JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer.

Which gives you weird stuff like https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration or https://keycloak.example/realms/<name>/.well-known/openid-configuration

OAuth Authorization Server Metadata Discovery in trying to be compatible with OIDC carries through this "appending" nonsense which isn't actually "well known" according to the well known spec: https://datatracker.ietf.org/doc/html/rfc8414#section-3

That's why it's appending to the issuer.

[germ-mark]

I think the structural pieces are basically in place. adding a few review questions