… LooseObjectsStep

These are the same commits as #1094 and #1116, now targeting `releases/shipped`.

If we have a corrupt loose object, the `git pack-objects` command will fail as it cannot put that object into a pack-file. This stops all future iterations of the `LooseObjectsStep` from succeeding, so users will be stuck in a bad situation.

* Refactor `WriteLooseObjectIds()` to rely on a new `LooseObjectsBatch()` method.

* On failure to create a pack, check all objects in the batch (using `LooseObjectsBatch()` and libgit2) and delete those that fail.

* Start disposing the repo in the dehydrate verb for safety.

* Create a functional test that verifies this behavior. Move the `LooseObjectStepTests` to have a new enlistment for each test, since we are messing with the object store. Part of the issue is that .NET doesn't allow us to move files that are marked as read-only, which becomes problematic as tests create pack-indexes and other files.

Resolves #1079

…t counts

We are having some flaky tests because _somtimes_ we get one too many or one too few loose objects in our `LooseObjectStepTests`. The only reason this can happen (as I see it) is that we are downloading a loose object due to the virtualization layer, and that file exists in a pack somehow. This causes us to delete or add an object during the `LooseObjectsStep` and have off-by-one errors. Instead of seeing 160 objects (for example) we see 159 or 161.

Relax the test conditions to verify that we did not delete all of the loose objects during the steps instead of requiring the count is exact. (We already relaxed this in one direction in #1116.)

…nmounting

These tests have been super-flaky and frustrating. After weakening the tests, but still finding places where the loose object count is not deterministic, I thought it was worth starting over with the full list of exact-count assertions. To avoid loose objects being added or dropped from the counts in unexpected ways, now we unmount the repo before counting the objects.

I ran the functional tests 20 times on this PR and only one failure, but it was in the `GVFS.FunctionalTests.Tests.EnlistmentPerFixture.GitReadAndGitLockTests.GitAliasNamedAfterKnownCommandAcquiresLock()` test, unrelated to this change.

Replaces #1162, #1198, #1116.

Fixes #1201.