This is in preparation for `rpm-ostree container`, which handles
unpacking RPMs as non-root.

At the moment, I'm copying code in from both ostree's libarchive bits
(fixable...may need to export some utility functions) and some
functions from libhif (harder, see:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-January/000297.html )

There's lots more cleanup to do here, but I don't want to block on the
resolution of the libhif changes.

This is just a tech demo.  Example usage:

```
mkdir -p ~/.cache/rpmostree-containers
cd ~/.cache/rpmostree-containers
rpm-ostree container init
cp /etc/yum.repos.d/CentOS-Core.repo rpmmd.repos.d
rpm-ostree container assemble bash
rpm-ostree container assemble httpd
```

This is a work-in-progress port against the libhif master + some
outstanding PRs.

This is really going to be the heart of rpm-ostree, so let's give it a
better name.

This helps unify some code more initially between the treecompose and
container bits.

It's the default for unprivileged composes if it exists.  This is an
incremental step towards always using the ostree repo.

It's what more components are standardizing on.

I debated config file formats a lot.  JSON is fairly awkward for
humans to write, and really painful to parse from C.  YAML is nice,
but also painful from C.

Both are fairly overpowered for what we really need.  Keyfiles
(desktop spec, `GKeyFile`) have a lot of limitations, but at least
it's used by systemd and `.desktop` files, and we already have a
parser.

We still parse the JSON treefiles, but internally convert them to
`GKeyFile` (which is in turn converted to `GVariant` for a canonical
form).

We need to do selinux first.

Right now we're doing the /etc -> /usr/etc inside the RPM import, but
we might as well do the /usr/local bits in both.  Also, use
/usr/share/rpm by default for treecompose too so that is unified.

Other things like systemd unit files and kernel handling are only
going to be used for host side composes.

Sadly, libhif keeps trying to auto-create it.  It'll need patching
there, and possibly in librpm.