framework: Add a JUnit backend

This adds a mostly compliant JUnit backend. It currently passes all of
its tests and jenkins happily consumes the xml we produce.

This needs to have some refactoring done in profile to make it 100%
compliant with the junit-7.xsd from upstream jenkins, (although I would
be comfortable for now pushing with the known non-optimal behavior if
Jenkins will accept it), because JUnit expects to be given the number of
tests for the initial metadata block, but we have no way to calculate
that number until after the run has started.  This is because of the
flattening pass in profile that flattens the nested directory structure
into a flat dictionary.

There are two options to solve this problem:
1) Flatten all.py and other modules. This is a lot of work and I have
   many work-in-progress branches to do just hat
2) Push the pass out to a public method and call it ahead of time. This
   seems really hacky to me, and I'd rather not do something that ugly.

Currently this patch just passes 0 for the test count unconditionally,
jenkins does not seem to have a problem with this.

This includes JUnit.xsd from the jenkins svn repository for piglit
framework unit testing. This is only used in the piglit python framework
unit tests.

v2: - Fix some spelling errors
    - Remove asserts that were used for development
    - Replace any '\\' in test names for the JUnit backend as well as
      '/'. This covers that case that Windows os.path.join() is used on
      test names; this uses an re.sub() instead of str.replace()

Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
results.py: Refactor fysnc support for code sharing

Having the option to fsync the JUnitBackend is obviously useful, and
code duplication is bad, so being able to share code between JSONBackend
and JUnitBackend is what we want.

I see two possible ways to handle this, with a decorator or with a mixin
class. The decorator is nice in that it doesn't create multiple
inheritance and all of the potential pitfalls that come from that,
although using a mixin neutralizes some of those problems. The mixin is
nice because it would allow sharing the init between the two, and it
would be able to dictate some of the structure of the class.

I first implemented the decorator, but felt that the mixin was cleaner
and easier to understand.

Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
run.py: Allow using piglit.conf to set default backend

This patch adds support to the piglit.conf to add a default backend. If
the config is empty and it is not set then 'json' will be returned (the
standard piglit json backend everyone knows and hates).

Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>