Refactor Auth Flow

[fisher60]

We have decided on a more secure and standard auth flow that will allow us to use AbandonAuth as it was intended (serving as an identity and OAuth provider for many different applications).

The flow is as follows:

1. Client initiates a login request to AbandonAuth and includes application ID and redirect UI to the backend. AbandonAuth verifies this is a valid app id and callback URI combo
2. login with discord, basic stuff,
3. redirect to AbandonAuth
4. Using the verified redirect URI from 1, forward the login request with an exchange token with identity permissions for AbandonAuth and possibly an aud of the application ID (redundant, but maybe more secure)
5. Use the exchange token to authenticate a user/identify user on abandon auth and using the backend's own access token. AbandonAuth confirms the exchange token is valid and the aud claim matches the authenticated developer application that sent the request
6. AbandonAuth sends a long-lived identify token for the user. This token does not have permission to login on AbandonAuth as the user, but just has identify permissions.
7. The user is now authenticated and the application can do whatever it deems fit with the user's session. Most likely the application will redirect the user to the correct, known frontend application as defined by the backend and either issue a new token, or allow the frontend to store the AbandonAuth token to keep the user authenticated.

This solution was originally identified in #29 to solve known security issues.

[fisher60]

We will need to replace the auth flow diagrams in the readme as well. An enhanced version of the above diagram should be created for use in the actual readme. It will contain clear descriptions of each step. It may be useful to include multiple, similar auth flows for different types of deployments (Separate frontend/backend, server side rendered applications, frontend only applications).

[fisher60]

New auth flow diagrams bumped to #61