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.

Previously, it checked for AssertionErrors, now we have to implement
need-unbare-repo check ourselves.

Assured unicode values are supported when reading the configuration,
and when getting author/committer information from the environment.

Fixes #237

However, it does so only on posix. The test-case will run on posix only
as well.
Please note that in theory, even on windows we will attempt to run hooks,
even though I am not sure that this will actually work.

Fixes #81

This will save IOPs, and make the code easier to understand (I suppose).

Related to #224