config: Refactor in preparation for adding set_config

With this change calling get_config() to set a default parameter is
no-longer supported.  It wasn't a good idea anyway as:

* It makes the generated documentation dependent on the environment in
  which it is built.
* Changes to the configuration at run time (made with the up and coming
  _set_config) have no effect until the next run.

The documentation is still correct as we already have support for pulling
the defaults from (the default) stbt.conf at build time in `api-doc.sh`.
This required updating the documentation to use the
`default: from stbt.conf` pattern universally.
stbt batch run: Fix spelling in help message
stbt batch: When run from source dir, use `stbt run` (etc) from source dir

Before this change, running `stbt-batch run` or `stbt-batch report` from
the source directory (for example, when run by the self-tests),
`stbt-batch` would use `stbt run`, `stbt config`, `stbt screenshot` and
`stbt --version` from the *installed* location, not the source
directory.

This meant that the self-tests were testing a combination of the
development version of `stbt batch` with the previous installed version
of `stbt run`. This also made it impossible for me to manually test
changes to `stbt.py` via `stbt batch` without running `make install`.

Note that to run `stbt --version` we use `/bin/sh` because `stbt` isn't
executable in the source directory (because it runs
`$libexecdir/stbt-run` etc so it would be confusing to a user who tried
to run it from the source directory).
config: Add `stbt._set_config`

`stbt._set_config` allows writing stbt config files.  This is required for
Smart TV support to allow storing the results of calibration, but it may
be useful elsewhere.

`stbt._set_config` is private and not exposed via the `stbt config` command
as, due to limitations of Python's `ConfigParse` it will currently remove
all comments and normalise all whitespace in the configuration file.  We
may be able to fix this in the future[1] such that we can provide the
function as part of the public API.

[1]: http://stackoverflow.com/questions/6620637/python-configparser-question-about-writing-comments-to-files
Merge remote-tracking branch 'wmanley/set-config'

* wmanley/set-config:
  config: Add `stbt._set_config`
  config: Refactor in preparation for adding set_config

Closes #102.
make check: Fix running from extracted tarball rather than git

Required for Debian packaging support as it by default runs the tests
before building binary packages.
Fix running `make check` when stbt is not installed

Some of the integration tests would fail if stbt was not installed.  This
means that the tests would have been running against (or at least affected
by) the installed version of stbt.  This is bad as the results from `make
check` are then misleading - the installed version may pass but the source
version which you want to check fails.

This commit fixes this issue by taking the sledgehammer approach - do a
`make install` into a sandboxed directory before running the tests.  This
has the beneficial side effect that the integration tests are now also
testing that `make install` works correctly and issues like this are
now unlikely to recur.

This is required for Debian packaging as Debian runs `make check` while
building a package, but is a good idea anyway.
Add support for generating debian packaging

The intention is to set up a Ubuntu PPA to ease deployment onto Ubuntu.

The packages in Debian wheezy (current stable) are unfortunately not
current enough to build and run stbt but it works with Debian testing.
rpm spec file: Fill in Version automatically

With this change the RPM spec file no longer has to be updated with each
release.  Apart from not repeating ourselves this lends itself to more
automation around the release process and the possibility of creating
development RPMs in a continuous fashion using the OpenSUSE Build Service.
rpm: Fix for building rpms for OpenSUSE

OpenSUSE, like Debian but unlike Fedora, expects `libexecdir=/usr/lib`
rather than `/usr/libexec`.  This commit fixes the spec file such that it
can be used to target both OpenSUSE and Fedora.
Add Makefile target obs-publish

Automates pushing stbt updates to the OpenSUSE build service.  The
instructions were going to get a bunch more complicated if we wanted
to add Debian support so this commit automates that process.

This - combined with the change to fill in the rpm spec file version
automatically - also opens the door to the possibility of hooking it into
travis such that we have an stb-tester-master repo so brave souls can run
against git master without having to `make install` themselves.
Merge remote-tracking branch 'wmanley/debian'

* wmanley/debian:
  Add Makefile target obs-publish
  rpm: Fix for building rpms for OpenSUSE
  rpm spec file: Fill in Version automatically
  Add support for generating debian packaging
  Fix running `make check` when stbt is not installed
  make check: Fix running from extracted tarball rather than git
Makefile: Portable implementation of `date -R` for BSD / OS X
stbt batch run: Fix stbt-version.log

Since 1dbb8ffa, `stbt batch run` wouldn't correctly record the stbt
version when stbt was run from the installed location (it only worked
when run from source directory). Instead, you'd see this on stderr:

    $prefix/libexec/stbt/stbt-batch.d/../stbt: No such file or directory

We can't find the `stbt` executable relative to `stbt-batch.d/run`,
because the former is in $bindir while the latter is in $libexecdir, so
the location depends on the packaging -- at most we could make an
educated guess.

Note that the selftest I've added does correctly detect the issue,
because since 4ffa6b6c `make check` installs stbt into a temporary
directory and runs the tests against that installation.
test-stbt-batch.sh: Run `stbt batch run` from outside git repo

Since 00ac5b67, the selftests for `stbt batch run` create a git
repository in the temporary directory where the tests are run, to
allow the tests to pass when run from a dist tarball. `stbt batch run`
expects the scripts it's given to be in a git repository, so that it
can record the revision of the scripts it ran.

This commit changes the selftests so that `stbt batch run` is executed
from outside a git repo, but the *scripts* passed to `stbt batch run`
are inside a git repo. I'm only doing this for hypothetical reasons:
What if there was a bug in `stbt batch run` that looked at the git
revision of the current working directory instead of the script's
directory.