fix: reject a non-numeric clockTolerance instead of silently ignoring it

[afonsojanu]

Closes #606.

verify() checks that clockTimestamp is a number, but there was never an equivalent check for clockTolerance. If you pass a string there, which is easy to do by accident since maxAge accepts strings, the exp/nbf comparisons turn into string concatenation instead of arithmetic. Infinity and NaN break the same comparisons in their own way. All three cases end up making the tolerance effectively unbounded, so a token that's actually expired still verifies fine.

Repro before this change:

const token = jwt.sign({foo: 'bar'}, 'secret', {expiresIn: -100}); // expired 100s ago
jwt.verify(token, 'secret', {clockTolerance: '5'}, console.log); // no error, token accepted

The fix just validates clockTolerance the same way clockTimestamp already is, and throws a JsonWebTokenError instead of letting it silently do the wrong thing. Added tests covering the string, Infinity and NaN cases, plus one confirming a normal numeric tolerance still works as before.

There was an earlier attempt at this back in #611, but it never got merged and had its own bug (the validation lived inside a .forEach callback, so returning from it didn't actually stop verify(), it just kept going). This is a fresh, smaller fix that doesn't have that problem.