Forking baazar to add Python 3.x support

[Richard Wilbur]

You folks make very good points.

It is becoming more clear to me that staying indefinitely with Python
2 (with no preparation for a transition to Python 3) would be akin to
thumbing our noses at the future.  Dropping support for Python 2 in an
abrupt jump to Python 3 would ignore the needs of bzrlib users and the
plugin ecosystem.  So the best option I can see is to start preparing
for the transition to Python 3 by moving the code to embrace the
newest aspects of 2.7 and compatibility libraries.

I am interested in what Python 3.4 will turn out to be, and especially
Python 3.5 as it sounds like it may provide the least problematic
transition from 2.7.  But since Python 3.5 is not expected to arrive
till 2015, I think we would be well served by starting the process
with Python 3.5 compatibility as a long-term goal and setting our
immediate sights on 3.3 or 3.4 depending on what's available when we
start.

The "Python 2 to 2&3 porting cheat-sheet"[0] offers what looks like a
reasonable strategy:

Step 0:  Setup.  Adjust required and installed Python versions.
Observe the tests passing on Python 2 and failing on Python 3.
    Presently bzr 2.6+ requires Python 2.6 which includes back-ported
features from Python 3.0.  In order to take advantage of back-ported
features from 3.1 it seems we would want to be using a recent release
of 2.7[1] and the consensus for 3.x seems to be 3.3+.  In other words,
the revised module would require Python 2.7 or 3.3+ in order to run.
Will that cause anybody problems?

Step 1:  Modern Python 2 code.
    Modernize the Python 2 code without introducing any dependencies.

Step 2: Working Python 3 code that still supports Python 2
    Get the tests passing first on Python 3 and then on Python 2 again
with the help of the 'future' package (from which we are already
importing absolute_import) and a PEP461 pure Python implementation for
byte %-formatting, et cetera.

This strategy could most effectively be applied to one module per
development branch with changes merged back into trunk at the end of
both step 1(modern python 2 code) and step 2(python 2&3 support)--in
both cases when the test suite works in Python 2 but the code has been
updated.

If we were to factor out some of the functionality to be standalone
(bencode, RIO, and the command line infrastructure have been
suggested), we could then treat them separately.  These components
would then need to be tracked as separate dependencies with individual
version requirements and releases.  What does that buy us?  I suppose
what comes immediately to mind is that anyone creating an application
that depends on one or more of these modules would no longer be
required to import the whole bzrlib.

[0]  http://python-future.org/porting.html
[1]  http://docs.python.org/2/whatsnew/2.7.html