Change the verification flow to support asymmetric algorithm

Hey @emarref , here comes a first stab at supporting async algorithms.
It required quite a lot of modifications, mostly around the key/secret management.
What I've done:
- algorithm classes now implement both 'sign()' and 'check()', both taking a key/secret as parameter
- the JWT serialize() and unserialize() take a key as argument (signingKey and verificationKey)
- the Context can be given a verificationKey as argument

Pending:
- Tests for the 'None' algorithm (it's very possible that it doesn't work)
- Fix some ugly 'require_once' in the RS algo tests (I am not yet super familiar with the autoloading)
- There's some duplicate code around preparing the message used by the signature - used both in Jws::getUnencryptedSignature and the AlgorithmVerifier::verify




Ok, we might need a different interface (or abstract class, so they can implement AlgorithmInterface) for the different sorts of algorithm

**assymetric-key algorithm**
createSignature() and verifySignature()  
(these seem to be the terms used in asym algos in this context, http://en.wikipedia.org/wiki/Public-key_cryptography)
Corresponding algos:
*RsaSsaPkcs*
*RsaSsaPss*

**symetric-key algorithm**
'createMac()'
Corresponding algos:
*Hmac*

'None' algo: would just implement AlgorithmInterface

Then the AlgorithmVerifier and Jws would need to identify the type of algorithm and then apply the relevant method.
It would be more verbose, but more explicit as well: the different behaviour of the different algo types would be reflected in the code. 

What do you think ?