Allow configuring a java.time.Clock in OAuth2Authorization.Token

Expected Behavior

It should be possible to configure a custom java.time.Clock on OAuth2Authorization
(via OAuth2Authorization.Builder), so that Token#isExpired(), #isBeforeUse(), and
#isActive() evaluate against the injected Clock instead of the system clock.

Current Behavior

OAuth2Authorization.Token#isExpired() and #isBeforeUse() compare token timestamps
(expiresAt, nbf claim) directly against Instant.now() / the system clock, with no way
to override this externally.

Context

Writing deterministic tests for token expiry, not-yet-valid (nbf), and revocation/refresh
flows currently requires either Thread.sleep(...), constructing tokens with timestamps
computed relative to Instant.now() at test-build time, or mocking static methods — all of
which are brittle or awkward. Injecting a Clock would make these scenarios reproducible
and independent of wall-clock time.

Start at OAuth2Authorization.Builder and OAuth2Authorization.Token, then trace how isExpired(), isBeforeUse(), and isActive() currently obtain the system time. Define the configured-clock behavior, including the default when no clock is supplied, and verify expiry, nbf, and revocation or refresh scenarios become deterministic without changing existing behavior.