Propagate user thrown exceptions.

Updated `validate` to work with `toUserLand` to propagate exceptions
thrown bu the user, so that user thrown exceptions are not caught and
fed to the user callback as Strata errors.

Created a `toUserLand` function that will mark an exception thrown by
the user callback as such, so that it is not caught by `validate` and
fed back to the user callback. The user land exception is assigned to
the `thrownByUser` variable. As the stack unwinds, if a `validate`
function catch the exception, it will check to see if it is the same as
the `thrownByUser` function. If it is, it will rethrow the exception.

Note that this means we hold onto the last user exception thrown until
the next user exception is thrown. There's no way of knowing how deeply
nested we are in `validate` callbacks, so we can't clear it as part of
the unwind.

We clean it up periodically by clearing `thrownByUser` in calls to
`cursor`, which ought to get called often enough to ensure that the
memory is freed. Also, we clear in `close`, in case that's the last we
hear from the user for a while.

I can't imagine the trickery the user would employ to make a delayed
collection of a thrown error cause problems for his program. Be warned
that errors thrown through Strata are going to be held by Strata for
some time.

The alternative would be to set a flag on the error. No garbage
collection issues, but that's even more obtrusive. I'd prefer to be less
obtrusive, but holding onto an exception is not entirely unobtrusive.

It's not perfectly unobtrusive. I am not afraid that this is going to
cause problems for users, or that anyone is going to accuse me of
leaking memory. It's theoretically obtrusive, but practically
unobtrusive.

The only case that occurs to me is in ES6 where the user may be tracking
the exception using a `WeakMap` and counting on the disappearance of the
exception in the map to mean something. Except that I've had a look, if
the user does not hold a reference to the `Error`, he can't look in his
`WeakMap` for an error.

Thus, deterministic and unobtrusive. Thanks for listening.

Closes #174.
Closes #173.