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))

This is aided by the new "vault_digests(data)" Sequel class method,
which can generate the digest array given the relevant keyring and
payload for the Sequel model in question.

While making this breaking change, also take the opportunity to convert
the digests to binary coding, which should be slightly faster and more
compact for equality matching.  It also streamlines attr_vault's code by
avoiding digest/hexdigest operator confusion.