Generalize build tree to support additional platforms/compilers/architectures

[nealkruis]

Description

Notes:

• Reviewers may want to make a fresh clone of the repo to test these changes, since they are likely not compatible with previous build tree structures.
• Came across a couple of hard-coded assumptions about where the executable is located that need to be reevaluted as we start supporting other platforms.
• Right now, we are only supporting building docs with 32-bit windows, that will need to change but requires a larger overhaul to the documentation process.
• The CI will run on other platforms, but they are set as "experimental" in the CI workflow so it doesn't complain about them failing. We can also comment them out if we don't want the CI to run for these cases.

Author Progress Checklist:

• Open draft pull request
  • Make title clearly understandable in a standalone change log context
  • Assign yourself the issue
  • Add at least one label (enhancement, bug, or maintenance)
  • Link the issue(s) addressed by this PR (under "Development" in the sidebar menu)
• Make code changes (if you haven't already)
• Self-review of code
  • My code follows the style guidelines of this project
  • I have added comments to my code, particularly in hard-to-understand areas
  • I have only committed the necessary changes for this fix or feature
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have ensured that my fix is effective or that my feature works as intended by:
    • exercising the code changes in the test framework, and/or
    • manually verifying the changes (as explained in the the pull request description above)
  • My changes pass all local tests
  • My changes successfully passes CI checks
  • Add any unit test for proof and documentation.
  • Merge in main branch and address resulting conflicts and/or test failures.
• Move pull request out of draft mode and assign reviewers
• Iterate with reviewers until all changes are approved
  • Make changes in response to reviewer comments
  • Merge in main branch and address resulting conflicts and/or test failures.
  • Re-request review in GitHub

Reviewer Checklist:

• Read the pull request description
• Perform a code review on GitHub
• Confirm all CI checks pass and there are no build warnings
• Pull, build, and run automated tests locally
• Perform manual tests of the fix or feature locally
• Add any review comments, if applicable
• Submit review in GitHub as either
  • Request changes, or
  • Approve
• Iterate with author until all changes are approved

[nealkruis]

@chipbarnaby this is ready for review again. A few notes regarding recent updates:

1. I've kept the same structure as originally proposed: "builds/windows-msvc-32". The reason for this is to make it easier to ignore all build content (without having to add new build configurations to gitignore every time we support a new one). The number of layers to get to the executables is the same (e.g., "builds/CSE.exe").
2. I've configured the executable names so that Windows MSVC 32 bit is still "CSE[d].exe". Any new configurations will be called "cse-compiler-arch[-config].exe" (e.g., on my mac it's "cse-appleclang-64" and "cse-appleclang-64-debug")
3. I've configured the reference results directories to be specific to OS, compiler, and architecture (they are all "release" configurations).
4. Regression tests will only be run if a corresponding ref folder exists.
5. I've added a setup for Visual Studio Clang