Metastore Search interface

In addition to these metastore APIs, we need to write a URI query parser to handle /search requests, as discussed here.

This is languishing, getting started and stopped again, and generally just not coming together. We think we know why now -- and it's because we don't really have any decent use cases for this. Once we implement our POST interface, all of our searches will be against that, and there will be no real need for a URI query.

With that said, a simple GET is still very useful - but we need to keep this -much- simpler than we were discussing. Once we started getting into a recursing URI query parser and data typing (date ranges vs integer matches) we realized that this wasn't a "simple" search at all, and were realistically re-inventing many a wheel.

So, to put a hard ceiling on what a "simple" search is, we're keeping the default 'AND' behavior and exact matches, adding wildcarding, and stopping there until a specific use case demands otherwise. :)

Ideally later, the POST interface will implement dav-style dynamic collections (aka saved searches in the metastore) that you can publish if you don't want full POST access to your store for searching, combined with some delicious ACL action.