Initial import of gcovr as a separate software package.
Updating the gcovr script.
Updating gcovr to include a URL pointing back to the FAST project Trac.
Bug fix.  Removing pyutilib directory, which was mistakenly added.
Tagging gcovr 2.0
Adding a dummy __init__.py file.  This ensures that 
the pyutilib.virtualenv preinstall works robustly.
Add attributes to xml format so that it could be used by hudson/bamboo with cobertura plug-in.
Changing the semantics for EOL to be portable for MS Windows.
Adding patch to scan for lines that look like:

  creating `foo'

as well as

  creating 'foo'
Adding error checking when no coverage results are found.  The line and
branch counts can be zero...

Adding logic to process the -o/--output option.  (Resolves #3870)
Adding fix to compare the absolute path of a filename to an exclusion pattern.
Adding an --object-directory option, which allows for a flexible
specification of the directory that contains the objects generated
by gcov.
Misc fix.
Specifying the absolute path for gcovr to process files.

Misc chang in debugging output.
Tagging gcovr 2.1
Adding basic tests for gcovr (based on reported tickets).
Adding timestamp and version attributes to the gcovr XML report (as
documented in #3877).  
  - it looks like the standard Cobertura output reports number of
    seconds since the epoch for the timestamp and a doted decimal version
    string.  
  - gcovr reports seconds since the epoch and "`gcovr `"+`__version__`
    (e.g. "`gcovr 2.2`") to differentiate it from a pure Cobertura
    report.  Please file a ticket if applications have difficulty
    reading the XML.
bugfix: gcovr was only including a `<sources>` element in the XML report
if the user specified `-r` (resolves #3869)
Overhaul of gcovr's logic for determining gcc/g++'s original working
directory.  This resolves issues introduced in the original
implementation of `--object-directory` (resolves #3872) and fixes #3883.
Overhaul of the `--root` / `--filter` logic.  This should resolve the
issue raised in #3884, along with the more general filter issue raised in
comment:ticket:3884:1