Work around deprecation of SoupServer's port property

See https://bugzilla.gnome.org/show_bug.cgi?id=732184
deploy: Consistently use fd-relative API

While looking to fix a different bug here, I found the current
state of things where we had a mix of fd-relative API versus not
frustrating.

Change the code around to consistently use *at, and also add some more
tests.
deploy: Clean up leftover state before creating new directories

This fixes a regression introduced with https://git.gnome.org/browse/ostree/commit/?id=7baa600e237b326899de2899a9bc54a6b863943c

The original code in "ostree admin upgrade" had a comment:

 /* Here we perform cleanup of any leftover data from previous
  * partial failures. This avoids having to call gs_shutil_rm_rf()
  * at random points throughout the process. */

But since I deleted that initial cleanup call, we *do* need to do the
cleanup during the process run.  It turns out there are only a few
places this is necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=733030
deploy: Remove legacy "current" symbolic links

Per comment, this was a temporary non-atomic hack, and it's time to
remove it.

https://bugzilla.gnome.org/show_bug.cgi?id=731051
Extract opendirat() helper function into libotutil

We were duplicating the code to do an opendirat() in a few places.
deploy: Copy parent directories for modified config files

Previously, in the case where a parent directory of a modified config
file was removed, we would throw an exception.  This happens when
switching from a tree that has some software (e.g. firewalld), to one
that does not.

While it's nice to have this warning that your config file probably no
longer applies, there's no need to make it so...fatal.

It's particularly problematic that the only easy workaround is to
remove the config files from your current tree - which breaks
rollback.

The solution then is for for us to take ownership of the parent
directories too into the new /etc.  Admins can clean up these files
afterwards at any time.

https://bugzilla.gnome.org/show_bug.cgi?id=734293
ostree admin: Fix return value from 'ostree admin [instutil]'

'ostree admin' and 'ostree admin instuil' with no arguments were meant to fail,
but the logic was wrong; add an assertion on the return value from all ostree
commands to catch similar problems in the future.

https://bugzilla.gnome.org/show_bug.cgi?id=737194
Pass --help to the most nested subcommand

'ostree admin <x> --help' and 'ostree admin instutil <x> --help' should
give help on the deepest subcommand, not on 'ostree admin'.

https://bugzilla.gnome.org/show_bug.cgi?id=737194
Fix help output for nested subcommands

Only 'ostree admin' was appearing in the help message for commands
nested within ostree admin.

https://bugzilla.gnome.org/show_bug.cgi?id=737194
ostree admin instutil: make --help work for subcommands

Even though the subcommands don't take arguments, use a GOptionContext
so that --help works as expected.

https://bugzilla.gnome.org/show_bug.cgi?id=737194
--help should always go to stdout

The standard convention is that the  output of --help should go to standard
output (so that it can be piped to a pager and searched.) See, e.g., the
GNU coding standards.

https://bugzilla.gnome.org/show_bug.cgi?id=737194
Add test for the behavior of --help

Recursive over ostree and all subcommands, and check that --help
is supported, properly outputs to standard out, and exits
with a 0 exit status. Check that for commands with subcommands,
they produce the help output to standard error when run with no arguments.

https://bugzilla.gnome.org/show_bug.cgi?id=737194
Followup to SoupServer port deprecation

My patch didn't actually work with newer libsoup.
trivial-httpd: Further fixes for previous commit
ostree admin instutil set-kargs: make more flexible

Add command line arguments:
 --import-proc-cmdline: import values from /proc/cmdline
 --merge: import current values
 --replace=ARG=VALUE: replace value
 --append=ARG=VALUE: append a new argument

Extra command line arguments are treated like --append=, which
gives backwards compatibility.

https://bugzilla.gnome.org/show_bug.cgi?id=731051
ostree admin: Add a --print-current-dir option

Add an option --print-current-dir that prints the current deployment
directory to stdout and exits.

https://bugzilla.gnome.org/show_bug.cgi?id=731051
Add test case for 'admin instutil set-kargs'

Test out the newly added options to 'instutil set-kargs' along with
the existing functionality.

https://bugzilla.gnome.org/show_bug.cgi?id=731051
Test 'ostree admin --print-current-dir'

Add a test for the --print-current-dir option

https://bugzilla.gnome.org/show_bug.cgi?id=731051
upgrader: Hold a ref to the origin

We unref it in _finalize, so we need to hold a ref.  I *thought*
this was the source of
https://github.com/projectatomic/rpm-ostree/issues/30

But apparently not =/
Add API to directly link() objects between repositories

And use it in pull-local.  As one might expect, this is blazingly fast
if they're on the same filesystem.

I'll be using this to "promote" builds between different repositories.