feat: Feature parity for a_decode_token and decode_token

[Krismix1]

I saw that the decode_token allows configuring the leeway (introduced as part of #568), but the same feature is unavailable in a_decode_token.
In an attempt to bridge the gap between, I refactored out the logic to validate the token, leaving the functions only responsible for fetching the public key.
Also fix the case with using validate=False + a key resulting in the validation still being executed.

There is a slight difference in the behaviour though, with regards to how key=None is handled:
Before:
A call like decode_token(token, validate=True, key=None) would be considered "okay", but fail with jwcrypto.jws.InvalidJWSSignature: Verification failed for all signatures["Failed: [ValueError('Unrecognized key type')]"] because the key was None.
With the new change:
The same call will fetch the public key and use it to validate the token.

I think it's an acceptable change in behaviour/API, as I doubt an exception was what consumers would want.

[ryshoooo]

Thanks a lot @Krismix1 LGTM