OCR: Silence miscellaneous output

Otherwise every time you use OCR you get:

    Tesseract Open Source OCR Engine v3.02.01 with Leptonica

printed in your logs. With this change logs are clearer and it's easier
to write interactive stbt scripts. This was required as the future
calibration program `stbt camera calibrate` is interactive in the
terminal and uses OCR.
stbt.py: [pylint 1.0] use new-style classes throughout

Pylint 1.0 insists on new-style classes, meaning that custom classes
must inherit from either `object` or another new-style class.
pylint.conf: [pylint 1.0] Ignore unused variables beginning with "_"

In pylint 1.0 the default value for "dummy-variables-rgx" changed from
"_" to "_$". So unused parameters like "_bus" in stbt.py's
Display.on_error were triggering the W0613 checker (Unused argument).
stbt lint: [pylint 1.0] work with either logilab.astng or astroid

Logilab renamed their `astng` module to `astroid`, but almost all of the
classes and functions that it includes have remained with the same name,
so we just include that import line in the 1.0 < pylint <= 1.0 try/except
block.

Note that I moved the E0611 (no-name-in-module) pylint warning to wrap
the entire block, and added F0401 (import-error) for `logilab.astng`.
stbt lint: '.png' does not count as a missing image file

The image path verifier should not raise an error for finding a string
that is *just* '.png' by declaring that the image does not exist on file.
It is completely understandable that users might want to use '.png' in
their code with it *not* referring to an image file. It would have to be
a hidden file, and I don't think anyone is crazy enough to use a hidden
file in their test scripts. '.png' is used as the `suffix` parameter
to a call to mktmp in stbt.py.

Note that the original regex was flawed in searching for r'.png' as this
matches any 4 character string ending with 'png' with '.' acting as a
wildcard. The new regex only returns True if it finds at least one
character followed by '.png', thus exluding simple '.png'
stbt lint: Don't refuse to work with pylint 1.x

The problems described in 97eada33 were fixed in our earlier commit
b893f23b.

The pylint problem described in 65a38380 has been fixed in pylint 1.0.1.
Fixes to pass pylint 1.1.0

The errors in irnetbox-proxy were W0633 (attempting to unpack a
non-sequence) because `IRNetBoxProxy.get_message_from_irnet` returns
`None` when its parameter `expect_sync_response` is False; pylint
doesn't figure out that these calls are guaranteed to return a sequence
because `expect_sync_response` is True. C0301 is "Line too long", and
is necessary for older versions of pylint that require it even when the
line length was exceeded by a pylint comment.

The remaining errors were C0325 (Unnecessary parens after 'if',
'return', or 'print' keyword). In the case of `print`, these same files
already had instances without parentheses, so we're not hurting python 3
compatibility.

I can't disable new checkers altogether in pylint.conf, because older
versions of pylint (0.28) will raise a `pylint.utils.UnknownMessage`
exception. At least I can disable new checkers with `# pylint: disable`
comments in the code itself, as long as I disable E0012 (Bad option
value; Used when a bad value for an inline option is encountered) in
pylint.conf.

Tested with pylint 0.28.0, 1.0.0, and 1.1.0 from macports.
Merge branch 'pylint-1.0-compatibility'

* pylint-1.0-compatibility:
  Fixes to pass pylint 1.1.0
  stbt lint: Don't refuse to work with pylint 1.x
  stbt lint: '.png' does not count as a missing image file
  stbt lint: [pylint 1.0] work with either logilab.astng or astroid
  pylint.conf: [pylint 1.0] Ignore unused variables beginning with "_"
  stbt.py: [pylint 1.0] use new-style classes throughout
stbt.as_precondition: preserve screenshot from intercepted failures

Just because the error comes from inside the `as_precondition` context,
to be marked as a "less interesting" failure, doesn't mean that there's
no value in keeping the screenshot from the intercepted Exception.

pylint W0201 is "attribute-defined-outside-init".
New tests that `stbt run` saves screenshot

This was already tested by `test_wait_for_match_no_match`, but it's
better to have an explicit test in the `stbt run` test suite, because
it's `stbt run` that saves the screenshot. In future when `stbt.py`
becomes an importable module that can be run from plain python, it won't
make sense for the `stbt.wait_for_match` tests to test the screenshot-
saving behaviour of `stbt run`.

Also added `test_that_stbt_run_saves_screenshot_on_precondition_error`
to test the behaviour/fix added in 98e682c0.
stbt.ocr: log text read by Tesseract

It can be nearly impossible to trace errors originating from an OCR
call because up until now the raw text read by Tesseract was not logged
anywhere in output, unless printed explicitly by the caller.
Merge pull request #101 from LewisHaley/log-ocr

stbt.ocr: log text read by Tesseract
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.