Enhance Generic OAuth to support non-standard Content-Type like text/plain;charset=UTF-8

### Description **Problem:** Grafana's Generic OAuth login fails with `oauth2: server response missing access_token` when the OAuth provider returns a valid JSON token response but with `Content-Type: text/plain;charset=UTF-8` instead of `application/json`. This is a real-world compatibility issue. Some enterprise identity providers (like IDaaS, Oracle IAM, etc.) return correct JSON bodies but with incorrect or non-standard `Content-Type` headers. While this violates the OAuth 2.0 spec, it's a common reality in enterprise integrations. Grafana currently relies on Go's `golang.org/x/oauth2` client, which strictly checks `Content-Type` before parsing the response. This causes login to fail even when the JSON body is perfectly valid. ### Example Response from OAuth provider: ```http HTTP/1.1 200 OK Content-Type: text/plain;charset=UTF-8 {"access_token":"abc123","token_type":"Bearer","expires_in":3600} ``` ### Grafana logs level=error msg="Failed to authenticate request" error="[auth.oauth.token.exchange] failed to exchange code to token: oauth2: server response missing access_token" ### Proposal Enhance Grafana's OAuth token exchange logic to be more resilient by: Attempt JSON parsing even if Content-Type is not application/json, as long as the response body is valid JSON. Add a configurable option (e.g. GF_AUTH_GENERIC_OAUTH_TOKEN_FORCE_JSON) to force JSON parsing for known misbehaving providers. Or, expose a way to override the expected Content-Type via config. This would improve compatibility with legacy or non-compliant identity providers without requiring reverse proxies. ### Workaround Currently, users must deploy a reverse proxy (Nginx, Envoy, etc.) to rewrite the Content-Type header, which adds operational complexity. ### Use Case Enterprise users integrating Grafana with internal IDaaS systems that cannot be easily modified. ### Version Grafana v9.5+ (using new authn system)