Bump version to 0.0.8
Add some paranoid synchronization around OpenSSL interactions

We have some evidence that green threads may be causing problems due to
OpenSSL thread-local state issues. Try to work around this by adding
coarse-grained synchronization to anything that touches OpenSSL.
Drop paranoid synchronization as it does not seem to help
Minor cleanup
Add different paranoid behavior

Try computing the hmac twice when saving, and compare the two versions.
These should always be identical, but we've seen some errors that suggest
that the hmac can be miscomputed in highly concurrent situations, possibly
due to thread-local state in openssl. This may tell us more about these
problems.
Bump version to 0.0.9
Use HMAC of the key over the secret to digest it

Primarily to avoid oracle attacks, whereby guessing a small space of
known to be valid outputs can be used to check the existence of a digest
in the data set.  The encryption key, known to be high entropy if
generated in a normal manner, being used to key HMAC should avoid that
attack.

As a downside, it is now more difficult and computationally expensive to
find encrypted values without decryption or compromising the contents.
It can still be done, however.  Prior to this patch, a program could
search for a value like this:

    WHERE digest_columm = digest(val)

Now, it will be necessary to digest using every HMAC key and checking
for a match. This seems acceptable if the keyring is kept fairly small,
as is the intended use.  For example:

    WHERE digest_column IN (digest_1(val), digest_2(val))
Make it easier to get a digest vector for matching

To aid with "IN" clause construction over a whole keyring in Sequel,
e.g.:

    FooModel.where(digest_field: vault_digests('needle-in-haystack'))