Changes are not consistently applied to v2 and v3

[mbyczkowski]

I have found a few cases were we have not been applying changes to either v2 or master branch (current v3 development). To make things clearer, I propose we only create PRs targeting master and then cherry-pick to v2 (when applicable):

• If PR for v3 also makes sense for v2 (say a bug-fix or a backward-compatible feature), let's label the PR V2-Cherry-Pick (or something similar), so we know a cherry-pick should be made onto v2 (and a person merging should create a separate commit with cherry pick).
• If PR is only to fix v2, then PR should be labeled accordingly, e.g. V2-Only.

Here's the list of (potential) discrepancies I have found to date:

master-only PRs:

• Support x5u, x5t, and x5t#S256 headers (for JWK) #242
• added error checking avoid nil referencing if error occurs #250
• Support RFC 7638 canonical kid for JWK #269
• add comments documenting cram is used for jose-util testing #274
• Fix typo in claims.go #280
• Document iat claim for jwt.Expected #289

v2-only PRs:

• Opaque key encryption/decryption v2 rebase #261 (but Add opaque key encryption and opaque key decryption #257 is opened and awaiting some more involved refactoring)
• [v2] performance: Improve ParseSigned whitespace stripping #279
• Better error handling around invalid headers #282

[csstaub]

I like this @mbyczkowski, let it be so.

[mbyczkowski]

Cool, I have created the labels and opened #291 and #292 to back-port and port-forward the missing changes. The remaining PR (#261) is being tracked already in #257.