Keys with associated versions

[aidantwoods]

As alluded to in #32, keys should to be strongly bound to their parameter choices to prevent algorithm confusion attacks (so byte arrays or similar shouldn't be accepted). From the PASETO spec:

PASETO Cryptography Key Requirements

Cryptography keys in PASETO are defined as both the raw key material and its parameter choices, not just the raw key material.

PASETO implementations MUST enforce some logical separation between different key types; especially when the raw key material is the same (i.e. a 256-bit opaque blob).

Arbitrary strings (or byte arrays, or equivalent language constructs) MUST NOT be accepted as a key in any PASETO library, [...]

I've opted to refactor the core PASETO operations into methods associated with each specific key (e.g. V2SymmetricKey has implementations for encrypt, decrypt involving its raw material). This means that the version level methods just need to do a type assertion checking that the given key matches the version, before deferring down to the key specific implementation.

Fixes #32