Clean block logs on points type delete

[JDGrimes]

Similar to #12.

However, in this case it is slightly more complex, because points type query args are incorporated into the block signatures. So this isn't just about trimming the block logs, this is actually about cleaning out whole blocks. And we really can't do that without knowing what args are behind their signatures. Since the signatures are hashes, we don't know which blocks belong to which points types.

[JDGrimes]

There at first might not seem to really be a need to do this, the only problem is that unnecessary data is left in the database. It isn't as with the users where errors will result from trying to display information about a nonexistent user.

However, although no errors will result, any queries for totals across all points types will be incorrect, because they will include the totals from the deleted points type. Of course, this mainly affects historical logs, and doesn't seem to be a particularly likely situation, that the user would decide to delete a points type when they had previously been wanting it in the totals for all types. Still, it is a potential issue.

[JDGrimes]

Perhaps the best thing to do is to go ahead and save all of the signature query args for each block, instead of only saving the generated signature. That will probably also come in handy in other applications in the future.

That really shouldn't take up that much room, although it really seems unnecessary to save the args for every single block, when many blocks will be for the same query and thus share the same signature and args. It seems like we ought to have a second table to store the signatures and args in. That way, we wouldn't have to pull up every single block and look at the args, we could just loop through all of the signatures looking at the args, and then only remove those blocks with those signatures that matched.

[JDGrimes]

In that case, we no longer need to store the signature itself in the blocks table either, only the signature ID. Which would also save significant space.

However, it would also be backward-incompatible for anything directly interacting with the database, or really even using the block logs query class. But I guess that this really isn't important at this point, because nobody is doing that.

[JDGrimes]

Since we're clearing out the database, we need to flush the caches, but we're already doing that with #12, so we're good there.

I did just happen to think thought, that since we are clearing out the caches, we can just delete the cache index rather than updating it. So let's do that.