New CipherService implementation

[Les Hazlewood <lh...@apache.org>]

I'm writing/cleaning up the cipher stuff to work as a CipherService
with essentially the same API as before, but it will also support
streaming operations.  One important change I've made thus far is that
the CipherService implementations will _not_ have a default
encryption/decryption key like they did previously.

I made this decision based on the CipherService API:  I created this
interface originally to mirror the mathematical concept of a cipher,
which accepts a key for each operation.  Now, if the implementation
has a default key, then the caller doesn't know whether or not to
supply one.  It is rather odd to have a method argument in the method
signature, and use a default value if not supplied at runtime - very
odd-feeling contract.

So I've removed the default key inside the implementation and pushed
the burden of maintaining a default to the CipherService caller if
they want one.  For example, the DefaultRememberMeManager can specify
a default key upon instantiation.  So there's still a default in
Shiro, but it's just not located in the CipherService itself.

Any objections?  Thoughts?

- Les