Option to use `Either` for catchable errors

[singpolyma]

Some errors can be handled at runtime by the downstream. This pull request adds "safe" variants of many functions to expose type-safe error handling to users that want it.

[acw]

Hmmm.

While I sympathize with the need, I find its implementation a bit clunky. Especially the double Either in _oaep_safe. I certainly think throwing predictable exceptions is probably a good change, rather than just using error, so that change should happen.

Do you have a specific use-case in which you need one of these routines to return an error value rather than throwing an exception? Because I'm tempted just to do the switch to exceptions and leave it there, rather than creating the (kind of irritating) duplication of all the main functions.

[singpolyma]

@acw I'm considering basing some functionality in one of my OpenPGP libraries on this code, but my library guarentees to users that pure code will not throw exceptions they are meant to catch, so my dependencies need at least the option to do the same.

[acw]

OK, that seems fair. Let me look at it a bit and see if there's a way to make this a little cleaner.

[acw]

This ended up being a larger change than I thought, because of the chaining involved. Also, doing the modifications exposed some issues I'd been meaning to handle for awhile. However! RSA version 2, which I have just uploaded, contains both Pure and Exception interfaces to the routines. You should be able to access the pure versions via Codec.Crypto.RSA.Pure, which does exactly what you asked for.