Issue #84: Unicode support in screen and ANSI.

Please see the commit message for details.

I'm not sure if I'm on the right track at all, so I didn't spend a huge amount of time trying to tidy the code, get the comments exactly right, etc.  I'm happy to fix that stuff up if I'm on the right track.  Apologies if I'm on the completely wrong track!

The screen and ANSI unit tests pass on Python 2.6, 2.7 and 3.3.

Some issues I'm aware of which I think are fairly minor:

It's not 100% clear to me which methods are meant to be public and
which are only meant for internal use, so I've tried to perform
decoding in all methods that accept input.

There are some cases (e.g. screen.fill(), fill_region(), put(),
insert_abs(), insert()) where decoding is performed by a method that
then invokes another method that also potentially performs decoding.
I thought that this was safer as it meant that future refactoring
wouldn't inadvertently result in decoding not being performed in some
code path.

Use of the incremental decoder from ANSI.write_ch() and
screen.put_abs() technically doesn't make sense, since those methods
expect to receive exactly one character, and if the caller actually
needs an incremental decoder to be used because they don't know where
the character boundaries are in the byte stream, they shouldn't be
calling those methods.  However, I've just used the same incremental
decoder in those methods as in all the other ones.  I assume those
methods probably wouldn't typically be called directly by outside
code, and if they were, the user would have to have more of an idea of
what they were doing with regards to multi-byte encodings.

With an incremental decoder, we're meant to call it once at the end
with final=True so that any incomplete byte sequence at the end of the
stream can be detected.  I don't know of a sensible way to do that -
perhaps screen() should have a close() method added to it that does
this?
This isn't set in stone, but my current thinking is:

- If the user passes an explicit encoding, it is used for both decoding and encoding, so that bytes roundtrip safely (assuming they're valid for the given encoding).
- If the user doesn't pass an encoding, it behaves the same way, with a default encoding of latin-1. This is a fairly common encoding, and accepts any byte you give it, so it's the closest to backwards compatibility for existing code that writes bytes to a screen instance.
- If the user passes `encoding=None`, then they are promising that they will never pass bytes in, only unicode, so it should throw an error on bytes input. However, it's probably still worth having a string repr on Python 2. Here I would probably pick UTF-8 as the default encoding, because it can encode any characters (though it can't decode any bytes, like latin-1 can).

If you prefer, `__str__()` can throw an error on Python 2 if encoding was None. In that case, I think we should probably define `__repr__()` as `self.pretty().encode('utf-8')` on Python 2. str() is supposed to be used in programs, whereas repr() is more for viewing objects in an interactive shell.