Slash and burn: build complexity begone!

[rmunn]

This PR radically simplifies the build by:

• Getting rid of the split between FW 8 and FW 9 builds now that we no longer need to build FW 8 versions
• Getting rid of mono5-sil entirely
• Getting rid of NuGet.targets in favor of a simple dotnet restore
• Getting rid of MsBuild targets in LfMerge.proj in favor of a simple dotnet build
• Getting rid of Test target in LfMerge.proj in favor of a simple dotnet test
• Getting rid of build/LfMerge.proj entirely and using LfMerge.sln as the entry point to the project
• Getting rid of the entire build directory tree as it's no longer needed!

The result is a build that runs much faster, won't fail when TeamCity goes down, and uses standard dotnet tools to build. With this change, we'll be able to run local builds on developer machines, without needing to run them inside a Docker image. That should allow running unit tests in VS Code using standard VS Code test-runner extensions.

---

This change is 

[rmunn]

With all these changes, the build has essentially boiled down to three (or four) steps:

1. dotnet build
2. (Optional): dotnet test
3. docker/scripts/create-installation-tarball.sh
4. docker build -t ghcr.io/sillsdev/lfmerge -f Dockerfile.finalresult .

The only bit of complexity left is that we do need to be able to build different lfmerge images for different model versions in the future, so when model version 7000073 comes out, we'll need to run steps 1-3 in a for loop:

# This is an array; see https://www.gnu.org/software/bash/manual/html_node/Arrays.html
DBMODEL_VERSIONS=(7000072 7000073)

# Run the build once for each DbVersion
for DbVersion in ${DBMODEL_VERSIONS[@]}; do
    dotnet build /v:m /property:Configuration=Release /property:DatabaseVersion=${DbVersion} LfMerge.sln
    docker/scripts/create-installation-tarball.sh
done

# Build final Docker image
docker build -t ghcr.io/sillsdev/lfmerge -f Dockerfile.finalresult .

[rmunn]

You could almost skip running the build in a Docker container at all, but that causes issues with shared libraries. For example, when I ran the build with dotnet build on an Ubuntu 22.04 machine, then ran the lfmerge image (which uses Microsoft's dotnet/sdk:6.0 image, which is based on Debian 11), lfmergeqm failed to run and I got the following error messages:

/usr/lib/lfmerge/7000072/LfMergeQueueManager: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib/lfmerge/7000072/LfMergeQueueManager)
/usr/lib/lfmerge/7000072/LfMergeQueueManager: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/lib/lfmerge/7000072/LfMergeQueueManager)

So building in the same environment that the image will run in is still a good idea, and we can't quite radically simplify the build down to a simple six-line shell script as shown in the comment above. BUT... the dotnet build and dotnet test steps do work well enough that you can debug unit tests without needing a Docker container involved. Which is a big win.

[megahirt]

What a great PR! A long time in coming. Thanks also to @josephmyers for laying the foundation, making this slash and burn possible.