Related to #248

Do not swallow non-zero exit status during push and fetch unless
we managed to parse head information.

This behaviour will effetively handle cases were no work was done
due to invalid refspecs or insufficient permissions.

Fixes #271

When pushing/pulling, we ignore errors unless it's exit code 128.
The reason for this is now made explicit to make clear that issues
are handled by PushInfo flags accordingly.

Related #271

It turned out that the index is not actually corrupted, which is good
news. What happens is that `git` writes `TREE` extension data into the
index, which causes it to write out the given tree *as is* next time
a `git commit` is executed. When using `git add`, this extension data
is maintained automatically. However, GitPython doesn't do that ... .
Usually this is no problem at all, as you are supposed to use
`IndexFile.commit(...)` along with `IndexFile.add(...)`.

Thanks to a shortcoming in the GitPython API, the index was
automatically written out whenever files have been added, without
providing control over whether or not *extension data* will be
written along with it.

My fix consists of an additional flag in `IndexFile.add(...)`, which
causes extension data not to be written by default, so commits can be
safely done via `git commit` or `IndexFile.commit(...)`.

However, this might introduce new subtle bugs in case someone is
relying on extension data to be written. As this can be controlled
through the said flag though, a fix is easily done in that case.

Fixes #265

However, it doesn't reproduce on the latest version of GitPython.
Maybe it's on an older one.

In repositories like

	> git branch -a
	* test
	> ls
	test

`repo.iter_commits` failed due to an ambigous argument
(`'git rev-list test`).
Now this cannot happen anymore.

fixes #264

While at it, all other invocations of .git in remote.py were reviewed

Fixes #262

Also move untestable documentation out of test.

Related: #234, #242

Latest version of it is required to show the issues travis shows as well