pkg/search: generic queries for camliRoot and 'child to' relation

Start using them in the publish handler, to ease the move to a
possibly stand-alone publish handler.

Context: http://camlistore.org/issue/365

Change-Id: I2781a345e024174e3bea8511b6cdc6f342d5a7c1
WIP: stand-alone publisher app

Still full of hacks, TODOs, shortcuts, and only working with devcam for
now, so please disregard any implementation detail for now.

The way it works so far is:

1) I kept the initial publish handler as it was and renamed it
oldPublishHandler. This one is still used to read the config given by
serverinit, and to initialize some stuff. The required parameters are
converted as env vars and passed to newPublishApp.
Later on, I'll remerge the old with the new and try to find a clean
way for the handler initialized by camli to bootstrap the app.

2) newPublishApp builds the publisher binary, starts the app from a
goroutine, and returns a handler that proxies everything to the app.

3) the app itself is a dumb http server, most of its code ripped from
camlistored.go. It only has a publish handler.

Question: I reckon we'll want one app to be able to handle multiple
publish prefixes (as opposed to one app per prefix). I'm thinking
the app still has one publish handler per prefix (as camlistored does
right now). Sounds good?

4) The new publish handler (that is used by the app) has most of the
fields that the old one had. The main difference is that instead of
having a search handler and a blob storage, it uses a client both to:
-do search queries
-fetch and store blobs
The storage part was trivial afair, but I haven't done caching yet.
The searches changes are mainly twofold:
-as you suggested, I tried using generic search queries everywhere I
could, so that required adding the necessary exprs and such to the
search handler.
-since we're not using a local search handler anymore, we cannot have a
long lived describe request, on which a lot of the describe code relies
on. (with DescribeSync, PeerBlob, Members, etc all reading from the
internal map of the request). So instead, I'm reusing to the maximum the
info in the Meta of a describe response, in order to avoid too many
describe requests. This can probably use more thinking, but it seems to
be working for now.

5) I removed some of the closure/js stuff, and I'd like to clean up all
of it, because it was barely useful anyway. And when we're ready, we can
think of a way to adapt the cool UI stuff Aaron did.

6) I think the main problem left is for the camlistored publish handler
to find out all the extra config parameters that the app needs, mainly
all the client config related vars. Because that info is not present in
the config specific to publishing that the publish handler receives. For
now they're all harcoded with the values used in devcam mode.

Does this sound like the right track so far? Shall I now keep breaking
all that into smaller CLs?

Change-Id: I281fdcbbe6a2bdf15607e75a21bc93b453f82c85