[Piglit] Port piglit framework to python3, round 2

[Dylan Baker]

This is a proposal for another go at moving to python3 for the
framework. Due to the amount of work that's gone into piglit over the
last few months and years the codebase is very modern, and the
transition is pretty straightforward, the only major change is the
bytes/unicode/str conversion, which isn't that hard for us since we've
already relied on the unicode class for a number of our string
interfaces.

So why python3, and why now?

The first argument for python3 is features. Feature work is ongoing in
python3, while python2 is in long term maintenance mode, and there are
features landing in python3 that will either allow us to simplify the
piglit code, or to enable useful features with minimal effort. Patch 2
provides a sane, portable timeout implementation for piglit to
demonstrate this.

The second argument I can offer is that linux distributions are starting
to make the transition to python3 as their default python version. Arch
and Fedora have already made this jump. For windows and OSX the python
foundation provides pre compiled binaries.

But what about platforms that don't have python3.3+ available?

Well, the goal of recently landed changes to the generators was to
hybridize the generators to work under either python2.7 or python 3.3+,
with the same code base, and this series doesn't change that, nor do I
have any plans to do so while there are still python2 consumers. The
goal being that tests (including generated tests) should be backportable
to the python2 branch without any changes being necessary.

The idea then is that directly before landing this code a python2 branch
of piglit would be forked and pushed to the upstream repository.  Those
that need python2 would be able to use the python2 branch for testing,
while upstream development would continue on master, which used python3.

Any changes that were strictly necessary to keep the python2 branch
working with the python3 branch would be backported, presumably by
myself, but the goal would be to minimize the number of python changes
backported. The one drawback here would be that if the summary format of
master (python3) changed it's unlikely that would be backported to
python2. Master would still be able to understand python2 generated
results, but not vice versa.

So, to sum up:

1) branch a python2 branch, tests should be able to cherry-picked/merged
   cleanly
2) python changes necessary to keep the python2 branch running would be
   backported
3) When python2 is no longer necessary for anyone the branch could be
   dropped.