Breaking python2.4 compatibility for bzr-2.4

[jbowtie at amathaine.com]

I'm firmly in the camp that people using legacy distributions can keep
using legacy versions of bzr or upgrade their Python.

* With respect to Windows, we're already on Python 2.6 - no issue there.
* It looks like latest OS X has 2.6 pre-installed, and we're shipping
app bundles for older OS X that use 2.6 - can someone who knows that
platform confirm?
* Current distributions are on Python 2.6 or higher - no issue there.
* Legacy distributions can upgrade to bzr 2.3 if they don't want to
upgrade their Python install - no issue there unless we change
repository formats (which would break launchpad integration), or they
can stick with what's in their repository as long as it's bzr 2.x,
right?
* Python 2.6 is packaged for all legacy distributions if they want to
run latest bzr - no issue there aside from intransigent system
administrators.

Requiring 2.6 allows us to start distinguishing between byte-strings
and actual strings in the code base. It allows us to start running
2to3 so we can identify and fix 3.x compatibility issues.

Some of the specific things we can leverage in 2.6:

* The ssl module - better ssl support for various transports
* The future_builtins module (ascii(), filter() and map() as iterables)
* Named tuples - cleaner code in places where we use tuples
* The @abstractmethod decorator - would be really helpful for foreign
VCS interfaces
* Byte literals - obviously
* The io module - layered I/O for file-like objects; in 2.6 mostly we
can leverage the formal interfaces for our file-like objects
* better exception flow and syntax (less ambiguous catch syntax,
try/yield/finally)

Also available in 2.5:

* python-ntlm  - for interacting with Windows servers; relies on hashlib module
* The with statement and context managers - for better resource
management; 2.6 expands on this
* Relative imports - much easier on plugin authors; 2.6 expands on this
* ElementTree module - useful for plugins that have to deal with XML

I've submitted a few patches in the past that were rejected due to not
being 2.4-compatible, so this would definitely spur me to contribute
more (particularly as I'm quite keen to move to 3.x as soon as humanly
possible). And bzr-tfs has some ugly code required to make it work on
2.4 that I'd really like to get rid of (conditional imports of
ElementTree and hashlib for starters).