Add authentication layer to WPGraphQL.

The GIST of Authentication should look something like this:

An authentication mutation with username and password should be sent to authenticate which will return a "refresh token" and "JWT token"

The refresh token is a long-lived token and is should be persisted in WP in connection with the user (user_meta), and can be revoked (temporarily or permanently) at any point.

A valid refresh token can be used to get a new JWT token later. If revoked, the refresh token will be invalid for getting a refreshed JWT token, and would need successful username/pw authentication to re-generate (if not permanently revoked). If permanently revoked, it would require admin action to allow the user to obtain new refresh/jwt tokens.

The JWT token is a short-lived, signed token that can be sent in the headers for future requests and will be used to pass the user down in the AppContext of GraphQL for use in authenticating resolvers. The JWT token should include user info, including role/capability info that can be used by resolvers to check if the user has proper permission for the resolver to execute.

So, typical client flow should look something like this:

• Client should first authenticate with username/password (over https) via a GraphQL mutation
• Client should receive refreshToken and jwtToken in the mutation response
• Client should persist the refreshToken and jwtToken however they want (LocalStorage, etc)
• For all future requests, the client should first ensure the jwtToken is not already expired
  -- If expired, Client should ask for a new jwtToken using the refresh token
  ---If refresh token is invalid (revoked, or other), a new token will need to be created via user/pass auth request.
• if jwtToken is valid, pass it down to resolvers in the GraphQL AppContext
• If jwtToken is invalid, the GraphQL request should not be executed at all

Typical server flow should look like this:

• Server receives authentication mutation with username/password.
• If valid, return jwtToken and refreshToken
  -- if no refreshToken exists in user's user_meta, and the user isn't flagged as not being allowed to generate a new one, a new token should be created and stored in user_meta connected to the user. This should be something totally unique to the user that can be verified whenever it's sent, but can be revoked at any time.
  -- jwtToken should have a short expiration (tbd) and should include pertinent info about the user's roles, capabilities, etc (as well as all the other standard JWT details)
• For requests that contain a valid refreshToken in the header, a valid jwtToken should be returned.
• For requests that contain a jwtToken, the token should be validated before executing GraphQL.
  if the token is invalid, GraphQL should not execute
  if the token is valid, the user should be populated into the GraphQL AppContext before execution, and should be passed down to all resolvers so each resolver can reference when resolving