stbt batch summary chart: Logarithmic y axis (test duration)

When a freak test ran for 10 (!) hours, every other test ended up flat
against the bottom of the chart, so the chart was next to useless. With
a logarithmic scale, the chart is useful when mixing long- and short-
running tests in the same report.
Merge pull request #229 from drothlis/log-y-axis

stbt batch summary chart: Logarithmic y axis (test duration)
release-notes: Prepare for 0.22 features
stbt batch run: Fix `UnicodeEncodeError` when printing Unicode strings

When stbt is outputting to a terminal it will choose the encoding of the
stdout and stderr streams based on the `LANG` in use.  When it doesn't
detect a TTY attached to stdout/stderr it will default to ASCII output.

`stbt run` outputs directly to the terminal.  `stbt batch run` redirects
the output of `stbt run` to `tee` and then to a log file.

This means that if you `print u"Alfonso Cuarón"` in a test script (or more
likely `print` the output of `stbt.ocr`) whether you get a
`UnicodeEncodeError` will depend on whether you are using `stbt run` or
`stbt batch run`.

Python 3 fixes this issue by falling back to encoding as utf-8 rather than
ASCII.

This is technically a backwards-incompatible change but I don't expect
that it will break any test-scripts in the wild.  In fact I think the
opposite will be true.  You could however make the argument that it would
be better to stick to Python 2, warts and all or make the jump to Python 3
proper rather than creating this weird middle-ground.  This would be a
stronger argument if `stbt` were a normal Python library which people were
using in web-servers and text-processing where complete understanding and
control over encoding is necessary, but for stb test scripts I think the
path of least-surprise is setting the encoding as in this patch.

This replaces `logging._debugstream` which was added to solve the same
problem, but just for calls to `stbt.debug`.  There is a subtle change to
the behaviour here too. Previously calling `stbt.debug(u"Alfonso Cuarón")`
would always write to stderr in UTF-8.  Now, if `stbt run` is attached to
a terminal and `LANG` is set to a non-utf8 locale `stbt.debug` will write
in a different encoding, or possibly `raise UnicodeEncodeError`.  This
seems fairly sensible as this is the same behaviour as Python 3.