git_refspec_transform: Handle NULL dst

Add a "dirty" state to the index when it has unsaved changes

Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
commands that reload the on-disk index to fail if the current
`git_index` has changed that have not been saved.  This will prevent
users from - for example - adding a file to the index then calling a
function like `git_checkout` and having that file be silently removed
from the index since it was re-read from disk.

Now calls that would re-read the index will fail if the index is
"dirty", meaning changes have been made to it but have not been written.
Users can either `git_index_read` to discard those changes explicitly,
or `git_index_write` to write them.

When the index is dirty, return GIT_EINDEXDIRTY so that consumers can
identify the exact problem programatically.

If the index is dirty, allow `GIT_CHECKOUT_FORCE` to obliterate unsaved
changes.  This is in keeping with its name and description.

Now that the index has a "dirty" state, where it has changes that have
not yet been committed or rolled back, our tests need to be adapted to
actually commit or rollback the changes instead of assuming that the
index can be operated on in its indeterminate state.

Test that any changes to the index will mark the index as dirty.  Also
ensure that when we initialize a new index, read the index contents
from disk, or write the index contents to disk that we reset the dirty
flag to zero.  Further ensure that an unforced read with dirty contents
(when the on-disk index has not changed) does _not_ reset the dirty
flag as we have not updated the contents of our index and our unsaved
contents remain intact.

Teach the index when it is "dirty", and has unsaved changes.  Consider
the index dirty whenever a caller has added or removed an entry from the
main index, REUC or NAME section, including when the index is completely
cleared.  Similarly, consider the index _not_ dirty immediately after it
is written, or when it is read from the on-disk index.

This allows us to ensure that unsaved changes are not lost when we
automatically refresh the index.

Don't manipulate the repository's index during stash; instead,
manipulate a temporary index and check it out.

This allows us to use the checkout mechanism to update the workdir and
the repository's index, and allows checkout to use its common mechanisms
to write data and handle errors.

Add tests that ensure that we re-read the on-disk image by default
during checkout, but when the `GIT_CHECKOUT_NO_REFRESH` option is
specified, we do _not_ re-read the index.

refspec: rename `git_refspec__free` to `git_refspec__dispose`

streams: openssl: Handle error in SSL_CTX_new

Since commit 630a6736 (refspec: add public parsing api, 2018-02-07), we
now have two functions `git_refspec_free` and `git_refspec__free`. The
difference is that the first one will free the structure itself, while
the second one will only free the structure's contents. Use our new
`dispose` naming pattern for the latter function to help avoid
confusion.

refspec: add public parsing api

Fix interaction between limited flag and sorting over resets

deps: fix implicit fallthrough warning in http-parser

Fix assorted leaks found via fuzzing

Always set the `index` in the `checkout_data`, even in the case that we
are not reloading the index.  Other functionality in checkout examines
the index (for example: determining whether the workdir is modified) and
we need it even in the (uncommon) case that we are not reloading.

When running `git_index_add_all`, we should write the index to disk so
that we can re-read it safely during status.

The index::reuc tests must test that the checkout itself succeeds,
otherwise subsequent tests are not valid.

In fact, the checkouts were failing because when checking out `SAFE`,
they cannot update the files that are in conflict.  Change the checkout
level to `FORCE` to ensure that they get updated correctly.

We add entries into the main index to correspond with the NAME entries
that we're going to test.  NAME entries store the results of conflicts
occuring with rename detection during merge, and they must correspond to
conflicts in the index.

This test was mistakenly adding regular entries.  The checkout
validation failed, since it requires NAME entries to correspond to
high-stage (conflict) entries.  Correct the test to actually create
conflicts.

SIGSEGV otherwise...

Verified that this breaks before the fix and passes afterwards.

Fix type confusion in git_smart__connect

Verify ref_pkt's are long enough

git__free is insufficient if the packet is a git_pkt_ref or another
type that requires freeing referenced structures.

If the remote sends a too-short packet, we'll allow `len` to go
negative and eventually issue a malloc for <= 0 bytes on

```
pkt->head.name = git__malloc(alloclen);
```

Nothing verifies that t->refs[0] is a GIT_PKT_REF. A remote can send
another packet type, ultimately resulting in a type confusion in
`git_smart__detect_caps`

Currently we fail to clear the sorting flag for revwalks when resetting.
This caused a poor interaction with the limited flag during a recent
patch. This patch clears the revwalk sorting flag and causes it to no
longer persist over resets.

GCC 7 has introduced new warnings for implicit fallthrough in switch
statements. Whenever there is no branch in a case block, GCC will watch
out for some heuristics which indicate that the implicit fallthrough is
intended, like a "fallthrough" comment. The third-party http-parser code
manages to trick this heuristic in one case, even though there is a
"FALLTHROUGH" comment. Fortunately, GCC has also added a strictness
level to the -Wimplicit-fallthrough diagnostic, such that we can loosen
this heuristic and make it more lax.

Set -Wimplicit-fallthrough=1 in http-parser's CMake build instructions,
which is the strictest level that gets rid of the warning. This level
will treat any kind of comment as a "fallthrough" comment, which
silences the warning.