git_buf_clear does not free allocated memory associated with a
git_buf. Use `git_buf_free` instead to correctly free its memory
and plug the memory leak.

Instead of hoping that we can get a racy entry by going real fast
and praying real hard, just create a racy entry.

If the underlying filesystem doesn't support better than one
second resolution, then don't expect that turning on `GIT_USE_NSEC`
does anything magical to change that.

Use legitimate (existing) object IDs in tests so that we have the
ability to turn on strict object validation when running tests.

When `GIT_OPT_ENABLE_STRICT_OBJECT_CREATION` is turned on, validate
the index entries given to `git_index_add`.

The index::nsec::staging_maintains_other_nanos test was created to
ensure that when we stage an entry when GIT_USE_NSECS is *unset* that
we truncate the index entry and do not persist the (old, invalid)
nanosec values.  Ensure that when GIT_USE_NSECS is *set* that we do
not do that, and actually write the correct nanosecond values.

Windows defines `timeval` with `long`, which we cannot
sanely cope with.  Instead, use a custom timeval struct.