Will be used in end-to-end testing scenarios

This will enable setting projects to specific commits before the test.

This test can now exercise the "reset project to known revision"
functionality in LexBox, proving that it works.

Give it a project code, get an FwProject back, it does the rest. (It's
the caller's job to dispose of the FwProject when you're done, though).

Also add test demonstrating that the helper works, and we can modify an
entry's citation form, then push the modified entry to LexBox.

Now test code doesn't have to deal with undo/redo accessors.

So far the test is failing, so it's not working yet.

Now, if you tag a test with `[Property("projectCode", "sena-3")]` it
will automatically restore the sena-3 project to its original state at
the end of the test. This will ensure idempotence even if tests fail.

It's causing overload ambiguity when you create an SRTestEnvironment
with no parameters. We'll just pass the port number in as a string.

Now we have one folder per test, and it's deleted afterwards if the test
passed. If the test failed, the folder is preserved, but it will be
deleted the next time the test runs, so investigate before re-running
tests if you need the files in the folder.

Now that temp folders are set up properly, we can run tests that clone,
commit, and push repeatedly: the LexBox project is automatically
returned to its original state at the end of the test, and the temp
folders are cleaned up prior to the next test being run.

Turns out the .fwdata file isn't updated until you call .Commit() on the
action handler.

Also renamed CommitChanges to CommitAndPush.

Also make it static so that tests can supply their own dependencies
without needing to create an instance of ConvertMongoToLcmComments or
ConvertLcmToMongoComments in order to use the method.

This causes a .ChorusNotes file to show up in the sena-3 project in
LexBox, thereby proving that it can be done. Later we'll turn this into
a real round-trip test of some kind.

LcmTestHelper was the wrong place to put CommitAndPush since that needs
to deal with URLs, and URLs are already being dealt with in SRTestEnv.

This will enable other code to just ask the test environment what the
lexbox username and password are, and not have to look it up from the
environment variables all the time.

If you run multiple tests that want to reset the same project, the
second one was erroring out because the zip file already existed. We
now use random names for the files and dirs in the reset-project
method so that this cannot occur.

Plus a basic test demonstrating creating a new project, which will
eventually move to the base class or the SRTestEnvironment class.

Even if we won't use other project types than FLEx, might as well keep
the enum the same as what LexBox uses, so that if we get a project type
response that we didn't expect, System.Text.Json will know how to
deserialize it correctly.

This gives us a known starting point for all end-to-end tests, without
needing to check the .zip file into the LfMerge repo.

Now any test method can just create a new project with a single line.

Failed tests will still leave the project in LexBox so that it can be
examined later.

Somehow, if the UploadNewProject test is run after the other BasicTests,
Mercurial isn't finding the newly-created project when the UploadZip
step runs. However, if UploadNewProject is run in isolation, then
Mercurial finds it. This is apparently a race condition involving
Mercurial's new project registration, which we can reproduce
consistently here.

To reproduce, run:

    dotnet test -l "console;verbosity=normal" --filter=Foo_

We should see:

About to reset sr-f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
About to upload /tmp/LfMergeSRTests/data/sena-3.zip to sr-f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
Done with reset and upload for sr-f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
Created sr-f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
Teardown for Foo_UploadNewProject
About to delete project ID f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
Successfully deleted project ID f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
Teardown for Foo_UploadNewProject completed

But instead we see:

About to reset sr-f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
About to upload /tmp/LfMergeSRTests/data/sena-3.zip to sr-f7f322b8-b6d8-47e9-bb2c-7dd30426a5a1
Teardown for Foo_UploadNewProject
Teardown for Foo_UploadNewProject completed

And the "Done with reset and upload" step is never reached, becaue the
LexBox server returns a 404 on the project when we upload the zip file.

Race condition fixed in LexBox, so we don't need the Console.WriteLine
calls any longer.

Tests continue to pass, so there are no hidden conflicts.

FieldWorks and liblcm use the FW_CommonAppData environment variable to
locate the folder where they should store things like writing systems
downloaded from SLDR. We want it set to a temp folder for E2E tests.

Currently pulls project down from LexBox and verifies data. Next step
will be to change data in a FieldWorks project, push that to LexBox, and
verify that LfMerge can resolve merge conflicts.

This simplifies the constructor a lot and ends up making tests that
clone FieldWorks projects a lot easier to write.

Most methods in SRTestEnvironment now access only static properties such
as the HttpClient, so most of them can now be made static as well.

This will allow us to check out the LF and FW projects separately, to
better simulate a true Send/Receive scenario.

Our first test from SynchronizeActionTests fully converted to do
end-to-end testing with a real LexBox instance, and working.

Slightly simplifies E2E test code

The code for updating glosses in FW and LF can be extracted into the
test base class, allowing the individual tests to become a lot more
readable as it's clear at a glance what's being updated.

The process of doing a Send/Receive to LexBox is also an obvious bit of
code to extract into a common method call. With this, the whole E2E test
ends up readable without needing to scroll.

The E2E tests aren't going to run the MkFwData executable, they're just
going to call the LfMergeBridge API directly when needed. Saves time.

Now that we're not modifying existing LexBox projects but rather cloning
them and creating new projects for each test, we don't need the entire
"roll project back to previous revision" code.

Not used in the current E2E test, but will be used in an upcoming test

Run `dotnet test --filter E2E_` to see `hg clone` return 404 on a
newly-created project. Won't happen every single time, but will happen
often enough that it's likely to cause problems. Solution is going to be
to make CloneRepoFromLexbox more resilient against temporary 404s.

As requested in code review

This ensures that the override will only affect the test it's set in,
rather than potentially affecting other tests if we forget to clear the
environment variable in a `finally` block.

Rather than assume that the test will be running against the sena-3
project, let's make the test grab an arbitrary entry (the first one that
the LexEntryRepository knows about) and use it. Since the entry whose
GUID we hardcoded was actually the first LexEntry sorted by GUID, this
currently has no effect as we're actually testing the same entry we were
before — but it will allow us to change the test later.

Since we're not going to be creating any other test fixtures derived
from SRTestBase, there's no point in having two base classes; it has
become over-engineering now that we've decided on just one E2E test.

Instead of the tests failing if LexBox isn't available, this will just
mark them as ignored.

Newer library allows passing in an HttpClient, so we don't have to copy
cookies around.

We keep the temp directory around if the test failed, but we dispose
everything else.

The library doesn't do this for us. This would be unsafe if we weren't
awaiting the result of TusPatchAsync, but by the time TusPatchAsync
returns, the FileStream is no longer needed.