Don't assert in git_checkout_tree

Fix some observed problems with incorrect diffs

Update the explanation to reflect our use of git_status_list_new() and
make the breaks in rocco more meaningful.

Clarify why GIT_STATUS_CURRENT and index_to_workdir don't always imply
each other. Fixes #1740.

We used to move `data_start` forward, which is wrong as that needs to
point to the beginning of the buffer in order to perform size
calculations.

Introduce a `write_start` variable which indicates where we should start
writing from, which is what the `data_start` was being wrongly reused to
be.

The last commit taught git_checkout_tree to actually do something
meaningfull, when treeish was NULL. This lets us rewrite
git_checkout_head to simply call git_checkout_tree without giving it a
treeish.

In git_checkout_tree, the first check tests if either repo or treeish is
NULL and says that eithor of them has to have a valid value. But there
is no code to handle the treeish == NULL case.

So, do something meaningful in that case: use HEAD instead.

Since all 3 checkout APIs perform the same operation with the options,
all of them should use the same const-ness.

preserve windows error numbers as well

This was never really working right because we were checking the
wrong flag and not checking it in all the places that we need to
be checking it.  I finally got around to writing a test and adding
actual support for it.

There were a lot more cases to deal with to make sure that our
merged (i.e. workdir-to-tree-to-index) diffs were matching the
output of core Git.

Sometimes the static initializer for git_diff_options cannot be
used and since setting them to all zeroes doesn't actually work
quite right, this adds a new helper for that situation.

This also adds an explicit new value to the submodule settings
options to be used when those enums need static initialization.

This is a little more intuitive than the turned-around option that
I originally wrote.

This changes `git_index_read` to have two modes - a hard index
reload that always resets the index to match the on-disk data
(which was the old behavior) and a soft index reload that uses
the timestamp / file size information and only replaces the index
data if the file on disk has been modified.

This then updates the git_status code to do a soft reload unless
the new GIT_STATUS_OPT_NO_REFRESH flag is passed in.

This also changes the behavior of the git_diff functions that use
the index so that when an index is not explicitly passed in (i.e.
when the functions call git_repository_index for you), they will
also do a soft reload for you.

This intentionally breaks the file signature of git_index_read
because there has been some confusion about the behavior previously
and it seems like all existing uses of the API should probably be
examined to select the desired behavior.

These changes fix the basic problem with GIT_DIFF_REVERSE being
broken for text diffs.  The reversed diff entries were getting
added to the git_diff correctly, but some of the metadata was kept
incorrectly in a way that prevented the text diffs from being
generated correctly.  Once I fixed that, it became clear that it
was not possible to merge reversed diffs correctly.  This has a
first pass at fixing that problem.  We probably need more tests
to make sure that is really fixed thoroughly.

Fix examples to make the important stuff more obvious

Warnings for Windows x64 (MSVC) and GCC on Linux

indexer: remove the stream infix

Improve bad URL handling

I'm not too happy about manually inserting < and > but those get
output as html tags otherwise.

Seems that regexp in Mac OS X and Linux were behaving
differently: while in OS X the empty string didn't
match any value, in Linux it was matching all of them,
so the the second fetch refspec was overwritting the
first one, instead of creating a new one.

Using an unmatcheable regular expression solves the
problem (and seems to be portable).

At some moment git_config_delete_entry lost the ability to delete one entry of
a multivar configuration. The moment you had more than one fetch or push
ref spec for a remote you will not be able to save that remote anymore. The
changes in network::remote::remotes::save show that problem.

I needed to create a new git_config_delete_multivar because I was not able to
remove one or several entries of a multivar config with the current API.
Several tries modifying how git_config_set_multivar(..., NULL) behaved were
not successful.

git_config_delete_multivar is very similar to git_config_set_multivar, and
delegates into config_delete_multivar of config_file. This function search
for the cvar_t that will be deleted, storing them in a temporal array, and
rebuilding the linked list. After calling config_write to delete the entries,
the cvar_t stored in the temporal array are freed.

There is a little fix in config_write, it avoids an infinite loop when using
a regular expression (case for the multivars). This error was found by the
test network::remote::remotes::tagopt.

Use gmtime() instead of gmtime_t()