Allow a leeway to be given for the iat claim verification

[denis1011101]

Adds an optional leeway to the iat verification. Refs #353.

Right now iat is compared exactly against the local clock, so a token gets
rejected as soon as the issuer's clock is slightly ahead of the verifier's.
There's no way to allow for that: the global leeway doesn't apply to this
claim, and iat_leeway was dropped in 2.2.0.

In #353 (comment) anakinj
suggested keeping the comparison exact and letting the caller say how much drift
is acceptable, so that's what this does:

JWT.decode(token, secret, true, verify_iat: { leeway: 30 }, algorithm: 'HS256')
JWT::Claims.verify_payload!(payload, iat: { leeway: 30 })

It defaults to 0, so nothing changes for existing code. The value is read from
the claim's own options, as in that comment, which keeps the old iat_leeway
name out of the API.

Refs rather than Closes, since the default behaviour stays as it was.

Checklist

Before the PR can be merged be sure the following are checked:

• There are tests for the fix or feature added/changed
• A description of the changes and a reference to the PR has been added to CHANGELOG.md. More details in the CONTRIBUTING.md

[anakinj]

Thanks, I like this approach — opt-in per-claim keeps the default strict, and I confirmed verify_iat: true still rejects a future iat.

iat: true raises TypeError via dig, but so do exp: true and nbf: true today. Consistent, so I'll fix all three separately.

Two optional nits:

• README.md:535 still says leeway isn't taken into account for this claim — readers will stop there and miss your new snippet below.
• Boundary cases in issued_at_spec.rb sit well inside/outside the window; exactly at the edge and one second past would catch a > vs >= slip.

[denis1011101]

Thanks! Addressed both nits in 11226259:

• Updated the README wording. I also moved the leeway and iat_leeway notes out of the RFC blockquote since they aren't part of RFC 7519;

• Added boundary specs at the exact limit and one second past it, with and without leeway.

The latest workflow run is waiting for approval.

[anakinj]

Thank you @denis1011101 for the contribution.