Custom filter API

Slight modifications on yorah's original pull request.

This adds a priority to filters so that when chained they are run in a sane
order.  If you were going to provide some filter that encrypted blobs going
into the ODB layer, for example, you would want to ensure that you were
CR/LF filtering the plaintext and not the ciphertext.

This also adds a free function on the git_filter callback so that filters
can free the buffers they allocate.  Note that this breaks from the prior
art in the custom ODB layer (which provides an allocator for backends):

1. Filters may not know how big the filtered output is to be.  Thus we would
   presumably need to provide both a `malloc` and a `realloc` to callers, and
2. Filters may be using other APIs that handle the memory allocation for
   them - for example, if a filter were to provide encryption on the way into
   the ODB then it may use some crazy crypto APIs and given the potential
   size of blobs it would be disappointing to make somebody alloc and copy
   yet again.

This also suggests that we have a single `apply` function (with a direction)
which makes things similar to the `should_apply` function.

Finally, we need not call `should_apply`, instead `apply` can decline to
perform filtering itself.  Having a `should_apply` is aimed at optimizing
the case where calling *any* filter is an expensive operation (maybe you
would not otherwise need to pull the entire blob into memory - see
`blob_create_internal` following two divergent codepaths for example).
Some code paths, however, would be the same and we can avoid a call through
the binding layer if we skip the `should_apply` entirely.

There were some other small changes like:

- Putting this all ino the `sys/` namespace.
- Underscores are special in clar test names, so I renamed the custom test to
  remove it.