Validation Options - Experiment 2: New approach using external `Validator` struct

[oxisto]

This PR is part of a series of experiments, to see which options we have to implement validation options in a backwards compatible way. I want to get a fell about our options first and some feedback from the community, before we implement all desired options. I am looking to gather feedback here: https://github.com/golang-jwt/jwt/discussions/211

Option 2 is creating a completely new struct, called Validator, which takes care of the actual validation. A validator takes certain options (using functional options), such as leeway, etc. and can be passed to a Parser If none is specified, the default NewValidator() is used.

Pros:

• New API gives us the option to "clean" the validation up from the start and design it the way we want it, potentially moving towards this new API in v5 and sort of making it "optional" in v4.
• It separates the validation logic from the actual claim, also removing some of the duplicated code from the claims.go file

Cons:

• We need a new interface (ClaimsV2 for now, can also be unexported probably) that is used to retrieve the needed values for validation (exp, nbf, etc.) to the validator. Currently, only jwt.RegisteredClaims implements this new interface. ParseWithClaims checks for the existence of this interface, if it does not exist, the old way of validating is used
• There is a slight problem with the Valid() function of a claim. As long as the default validator without any options is used, it is fine. However, if a validator with options, e.g. is passed to the Parser, this validator is used inside ParseWithClaims and it is also used to set the token.Valid flag, which should be the canonical way to check, if the token is valid. However, if the user calls Valid() on the claim, this will not take the validator with the options but the default one (because we have no way to supply the validator to the claim in this PR). Therefore, we should probably deprecate Valid() and make a strong hint, that it should not be used, if used with validation options.

[oxisto]

Closing this for now as we are preparing for a new v5 api-breaking solution.