Refactor SyncAction tests to use real FwProjects pushing to local Mercurial server

[rmunn]

Fixes #346.

This PR converts all the SyncAction tests to use a real FwProject and call liblcm methods in order to edit it, rather than using pre-edited data in the testlangproj-modified project. This makes the tests easier to read (a LOT easier in some cases), as the changes expected in the FW project are visible in the test instead of being hidden away in non-code data. It also is a lot more flexible in terms of what kinds of future tests can be written, because it will be much simpler to load up a FW project and make whatever changes are needed.

One SyncAction test, testing a FW regression, was not converted; see #347 (comment) for the rationale. (Briefly, it's because I wouldn't be able to prove that the regression test was still testing the right thing).

[rmunn]

There's one more test, SynchronizeAction_CustomReferenceAtomicField_DoesNotThrowExceptionDuringSync, which could in theory be converted to use FwProjects instead of the old approach. However, it's essentially a regression test: there used to be a bug in FieldWorks 8.x that was causing certain custom fields to throw an exception when the FW value was converted to Mongo. There's workaround code in LfMerge to avoid that FW bug, and the test is verifying that with the workaround in place, those custom fields can be imported without error.

Thing is, apparently the FW bug was fixed at some point between 8.x and 9.x, because when I removed the LfMerge workaround code, the test continued to pass. So either I wrote that test wrong in the first place (doubtful), or else the liblcm code fixed the bug sometime in the past few years.

Which makes me a little cautious about making any changes to the regression test, as it was a rather complicated setup and since I can't make the test fail at the moment, I can't prove that any changes I make are still actually exercising the bug that used to be there.

So I've decided not to touch the SynchronizeAction_CustomReferenceAtomicField_DoesNotThrowExceptionDuringSync test. We might remove it in the future, but for now let's leave it in place as a regression test, to ensure that the FW bug doesn't come back.

[github-actions]

Test Results

    2 files  ±0    21 suites  ±0   6m 1s ⏱️ +24s
316 tests +1  294 ✔️ +1  22 💤 ±0  0 ❌ ±0 
319 runs  +1  297 ✔️ +1  22 💤 ±0  0 ❌ ±0 

Results for commit e7bc87a. ± Comparison against base commit 96284f7.

♻️ This comment has been updated with latest results.

[hahn-kev]

left a couple comments. Something that I realized looking at the verification code. In these Synchronize tests we're only verifying against the mongo db. Is there another test class where we verify what changes were applied to the FW Project?

[rmunn]

Build was failing because it was building against the potential merge commit, where I had changed one API in the MongoConnectionDouble class. I hadn't noticed the API change because when I tested locally, I was running against the branch head, not the potential merge commit. So GitHub's default PR target just helped me NOT break the develop branch once the PR is merged!