Verifier.verify raises very general exceptions

[cjwatson]

Verifier.verify can raise at least:

• MacaroonVerificationFailedException (various causes)
• UnicodeDecodeError (if a first-party caveat isn't valid UTF-8)
• TypeError (if a first-party caveat's signature fails binascii.unhexlify)
• ValueError (if a third-party caveat's verification key isn't well-formed)
• nacl.exceptions.CryptoError (if decrypting a third-party caveat's verification key fails)
• perhaps other possibilities that I missed

The TypeError here is particularly egregious since it's an exception that one shouldn't normally need to catch but that could easily come up due to non-well-formed input data, but the others are a problem as well. This is worse than #50 because verification often requires supplying predicate functions and so the amount of code that can end up being enclosed in try: / except Exception: can be pretty large.

It should be guaranteed that Verifier.verify only raises MacaroonVerificationFailedException or its subclasses plus whatever might be raised by caller-supplied predicates; and the possible exceptions should be documented.

[ewjoachim]

Verifier.verify() can also raise whatever was raised in a callback added through satisfy_general(), and this is, I'd say, a good thing, because errors should never pass silently. But this could (and did) encourage people to raise in their satisfy_general instead of returning False, which is an API misuse.

Should arbitrary exceptions in callbacks be caught and turned into MacaroonVerificationFailedException or left as-is ?