Thread provider_configuration_opts's request_opts into token/userinfo/introspection/client_credentials calls

[Taure]

Follow-up from the #7 security review.

#7 threads provider_configuration_opts (specifically its request_opts.ssl) into the discovery/JWKS fetch only (oidcc_provider_configuration_worker). oidcc also accepts request_opts => #{ssl => [...]} on the credential-bearing calls this library makes elsewhere:

• oidcc_token:retrieve/5 and retrieve_userinfo/5 - nova_auth_oidc_controller.erl:140,142
• oidcc_token_introspection:introspect/5 - nova_auth_oidc_introspect.erl:28
• oidcc_token:client_credentials_token/4 - nova_auth_oidc_client_credentials.erl:55

These are currently called with #{} / opts maps that don't carry request_opts, so a consumer who pins a private CA for discovery gets an inconsistent trust policy: the JWKS fetch is pinned, but token exchange (which ships client_secret and receives the ID token) and userinfo/introspection/M2M calls are not.

Not urgent for asobi specifically - asobi only reaches nova_auth_oidc_jwt:validate_token/3, whose sole outbound call is the JWKS fetch #7 already covers - but a real gap for any consumer using the full auth-code flow, introspection, or client-credentials against a provider with a private CA.

Fix shape (same pattern as #7, one level down):

RequestOpts = maps:get(request_opts, nova_auth_oidc:config(AuthMod, provider_configuration_opts), #{}),
TokenOpts = #{
    redirect_uri => RedirectUri,
    nonce => Nonce,
    pkce_verifier => PkceVerifier,
    request_opts => RequestOpts
},