./configure may have been called with an absolute path, and the
resulting srcdirs will contain absolute paths, which will end up
in the gcno files.

Previously we would print out entire patches and then annotate
them for coverage. This worked poorly for new files added, when
most of the file had coverage.

Rework the patch hunks and only print out N lines of context
around uncovered lines.

Also don't treat unchanged lines as uncovered by default. This
can be overridden by the --cover-context option.

Lastly parse the git diff command and only allow relevant options
through. We needed to do this to get access to the number of
context lines in use.

Noticed by pyflakes.  I've no idea what sort of errors it could've
caused at runtime.

 * Ask gcov to resolve what source files a gcno file represents.
 * This also covers issues with multiple gcno files for the same
   source file, as would be the case if a source file is built
   into multiple executables/libraries.

No gcno file indicates that the the source was not built with
code coverage. If the gcno file exists but predates the source
file, then probably not rebuilt since last change.

gcov needs to be run in the same directory as gcc was run in order
to find the source files correctly. We use gcov with --no-output to
report which directory this is for given gcno files.