Type safety on the 'purpose' and KeyInterface intent disambiguation

[aidantwoods]

This is based on my other PR to avoid conflicts since some of the same code is changed.

I found #36 while doing this refactoring, but this does nothing to address it (hence WIP). It merely replicates the previous behaviour.

I've also removed what I think was some redundant code in the JsonToken::withKey etc... (to avoid refactoring to an identical implementation twice).

Things can be improved in this PR, this just to test the waters on the general idea.

[aidantwoods]

A ("just for fun" at the moment) extension to this might be trying to equip Purpose (and other manually constructed enum style types) with enum features from other languages, like creating a custom switch-case construct to enforce exhaustivity of cases, e.g. https://github.com/aidantwoods/paseto/compare/bbf271094280788eb4de086056203c744723e3cc...aidantwoods:poc/exhaustive-switch-case

(PHP doesn't really have to tools to express function signatures as a type for closures, or the ability to enforce type safety when concrete class names aren't known so I think this probably ends up being worse off than the original unfortunately. Still, interesting experiment).

[aidantwoods]

I've rebased on master and added some new interfaces as mentioned in https://github.com/paragonie/paseto/issues/36#issuecomment-370103590 :)

[aidantwoods]

Provided we're okay with Purpose objects being able to be compared, 9056d72 removes the equality fuzzing and 81ca5ce makes use of the equality to avoid converting the object to a string when it's not needed (which makes the switch-case's look a bit nicer too IMO).