subprocess returns binary types, this is bad as diff-cover tends to use unicode

I am mildy concerned with this fix as my diff-cover has taught me that even with python3 encoding is hard....

OK so here is the issue

https://github.com/edx/diff-cover/issues/94

When diff-cover tries to root_rel_path

```
root_rel_path = os.path.relpath(cls._cwd, cls._root)
```

cls._cwd is passed in as unicode while cls._root is grabbed from the subprocess call.

Subprocess returns bytes, mixing bytes and unicode is BAD. 

```
>>> os.path.relpath('/Users/bachmann', '.')
'../../..'
>>> os.path.relpath('/Users/bachmann', b'.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/bachmann/Code/diff-cover/.tox/py34/bin/../lib/python3.4/posixpath.py", line 451, in relpath
    start_list = [x for x in abspath(start).split(sep) if x]
TypeError: Type str doesn't support the buffer API
```
For the record that error is unhelpful in this context so....: http://bugs.python.org/issue21883

Now usually encoding from subprocess is tricky work because "Whats the dang encoding?!" but.... 
https://www.kernel.org/pub/software/scm/git/docs/git-rev-list.html

>--encoding[=<encoding>]
The commit objects record the encoding used for the log message in their encoding header; this option can be used to tell the command to re-code the commit log message in the encoding preferred by the user. For non plumbing commands this defaults to UTF-8.

So I should be able to just decode utf-8... right?

This fix raises questions

1. Is there anywhere else we make this or a similar mistake. (looks like the other subprocess calls get decoded so we may be ok?)
2. In this example I am trying to fix do we ever pass cwd as bytes (we should not as long as all input gets decoded)? 
3. Is there a test to add?
If for some reason we get back a unicode object. I *think* this only happened in our tests when we patched it to do so but I am not 100% sure so I went with the cautious route.