Conditions hashes

First pass on allowing filtering and locking by hashes (and sql strings) as well as blocks.  Hash and sql based filtering is orders of magnitudes faster than block-based.  Sanitizers are left as blocks because 1) They are trickier to do otherwise, and 2) They operate on the 'shrunk' database and so are not very performance sensitive.

Mixing of block-based locks & filters with hash/sql string based filters is only partially supported.  Given the magnitude of the performance improvements, I'm inclined to restrict to only hash & sql based approaches, but not ready to pull the trigger on that without additional feedback.
yeah, filter.opts will be either a string with something like 'id % 1000 = 0' or a hash with something like {domain: 'apartmentlist.com'}

lock_opts similar.  It probably should be it's own object, but I think I'll defer that for future refactoring.

conditions is unused because rather than a targeted deletion we're deleting everything except a set of restrictions.