Fallback to PKCE RFC parameter names

[scotttrinh]

I played it a little fast-and-loose when implementing our PKCE implementation since we are not an OAuth authorization flow and therefore are not building an actual PKCE flow, just something inspired by it. However, there are some existing tools that can take advantage of the code exchange if we align with the same parameter names outlined in RFC 7636.

Added a note in the docs for anyone who might be familiar with how RFC 7636 defines PKCE to highlight the differences.

Closes #7026

---

Special note here about omitting support for code_challenge_method:

If the client is capable of using "S256", it MUST use "S256", as
"S256" is Mandatory To Implement (MTI) on the server. Clients are
permitted to use "plain" only if they cannot support "S256" for some
technical reason and know via out-of-band configuration that the
server supports "plain".

RFC 7636 Section 4.2

Since our PKCE flow is always a server-to-server flow, we require that clients provide a SHA256 hashed challenge, and do not accept plain as a code_challenge_method since it negates the added security of PKCE. The RFC specifies that if the code_challenge_method is omitted that the server treat the challenge as plain, but we do not support plain. I considered conforming here but always requiring implementors to provide the constant S256 value, but that seemed low value and an unnecessary hurdle. In the future we could chose to require it and return a failure status of 400 if you do not provide it if we want to add additional compatibility with RFC 7636.