release-notes: Prepare for 0.22 features
API: `is_screen_black`: Make `frame` parameter optional

This makes it consistent with the other functions such as `match()`, and
makes it more useful with a hypothetical `wait_until`, allowing
constructions such as:

    assert wait_until(is_screen_black)
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.
Merge branches 'utf8-output', 'is_screen_black-optional-frame' and 'tracing' into one