ostree daemon/shared library approach

[Colin Walters <walters verbum org>]

In

https://github.com/projectatomic/rpm-ostree/pull/116

We're discussing a daemon for rpm-ostree.  This has several intersections
with ostree, notably around any administrator use of the `ostree admin` CLI.

Now, Endless has had an ostree daemon for some time:

https://github.com/endlessm/ostree/tree/master/src/daemon

What I'm presently thinking though is that the correct approach
here is to continue down the path of "ostree as shared library",
where we expect people to write higher level tools on top.

In that case, the core `libostree` should have all necessary APIs
to write a useful daemon externally.

Further, the `ostree admin` commands should be regarded as
"demonstration only".  In fact, I'd go so far as to suggest
that for e.g. rpm-ostree managed systems, the `ostree admin`
commandline should be disabled.

One thing I'm thinking about is a "plugin" model where
projects like rpm-ostree can drop /usr/lib/ostree/admin-plugins/rpm-ostree.so

OSTree would iterate over these, see if they're "active" (in the
case of rpm-ostree, that's having the daemon running), and if so
call into them.

Perhaps the expected admin UX here is then:

# ostree admin status
error: This system is managed by rpm-ostree; use rpm-ostree status

Ugly, but keeps things clear.

I'm curious about thoughts from Endless people around this.  The
TL;DR is I'd suggest 

- The current daemon code move into https://github.com/endlessm/eos-updater
- We make static deltas work for your use case
- We also merge more of any outstanding size metadata work

Thoughts?