As git_annotated_commit seems to behave like cgit's refish, it's quite
helpful to abstract away "targets" via git_annotated_commit_from_id/from_ref.
As the former is accessible via git_annotated_commit_id, make the latter
also available to users.

patch_parse: populate line numbers while parsing diffs

Fix git_worktree_validate failing on bare repositories

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...