fix: honor UseOauthSpecScope when marshaling OAuth2 connection scope

[Asarew]

🔧 Changes

Fixes ConnectionOptionsOAuth2.MarshalJSON to honor UseOauthSpecScope.

Before this change, MarshalJSON unconditionally emitted scope as a JSON array (["a","b","c"]), regardless of UseOauthSpecScope. Auth0's backend then persists that array as a comma-joined string and forwards it verbatim to the upstream IdP on /authorize, so RFC 6749-compliant IdPs (Keycloak, Ory, ...) reject the entire value as one invalid scope literal (invalid_scope: a,b,c). The UseOauthSpecScope field added in #699 was accepted by Auth0 and reflected in the dashboard checkbox, but never changed the wire format — it only affects per-authorize connection_scope extras server-side.

With this change, when UseOauthSpecScope == true, scope is marshaled as a raw space-delimited string ("a b c") — the form spec-compliant IdPs expect, and the same form the Auth0 dashboard produces when the "Separate scopes using a space" checkbox is on. When false or nil, the existing array behavior is preserved for back-compat.

Types and methods changed:

• ConnectionOptionsOAuth2.MarshalJSON — split the scope write into two branches keyed on GetUseOauthSpecScope(). No new API, no removals.

UnmarshalJSON already accepts both the array and the string forms, so no change was needed on the read path — round-tripping is preserved.

📚 References

• Fixes: use_oauth_spec_scope=true has no effect on stored/forwarded scope for oauth2 custom social connections (follow-up to #1465 / #1480) terraform-provider-auth0#1656
• Follow-up to: Add UseOauthSpecScope field to ConnectionOptionsOAuth2 #699 (which added the UseOauthSpecScope field but did not wire it into serialization) and Add useOauthSpecScope option to OAuth2 connection terraform-provider-auth0#1480 (which exposed the field through Terraform schema).
• Also referenced by the reporter of Support useOauthSpecScope for custom oauth connections terraform-provider-auth0#1465: "I attempted to send scopes as a single item, space-delimited string array (e.g. ["scope1 scope2 scope3"]), but this resolves back to a comma-separated list." — that observation is exactly what this PR fixes.

🔬 Testing

Automated: extended TestOAuth2Connection_MarshalJSON with two new cases (UseOauthSpecScope=true → string, UseOauthSpecScope=false → array) and added a {"scope":"foo bar baz"} row to TestOAuth2Connection_UnmarshalJSON to make the round-trip through the newly-emitted string form explicit.

$ go test -run TestOAuth2Connection ./management/ -v
=== RUN   TestOAuth2Connection_MarshalJSON
--- PASS: TestOAuth2Connection_MarshalJSON (0.00s)
=== RUN   TestOAuth2Connection_UnmarshalJSON
--- PASS: TestOAuth2Connection_UnmarshalJSON (0.00s)
PASS

Full connection marshal/unmarshal suite also passes (TestConnection.*Marshal|Unmarshal|TestGoogleOauth2Connection.*).

Manual end-to-end (against a real Auth0 tenant, on a custom social oauth2 connection to a Keycloak-backed IdP):

1. Configure the connection with UseOauthSpecScope = true and scopes ["openid","profile","email"].
2. With go-auth0 pinned to this branch, PATCH the connection.
3. Inspect the connection in the Auth0 dashboard — Advanced Settings → Scope field now reads openid profile email (space-delimited) instead of openid,profile,email. The "Separate scopes using a space" checkbox is on.
4. Initiate login via the connection — the upstream IdP receives scope=openid profile email and login completes. Previously it received scope=openid,profile,email and failed with invalid_scope.

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)