Major refactor

[mrexodia]

This is a huge refactor doing the following things:

• Add an alternative cxx-common implementation as a superbuild project. You can find more information here: https://github.com/LLVMParty/packages/blob/main/dependencies.md. This is of course optional, but makes it much easier to users to build the dependencies necessary for remill.
• Cross-compile the semantics instead of the current hack with g++-multilib and -m32. The semantics are now compiled as -ffreestanding and just enough of the C++ standard library was implemented in a fake --sysroot to make it work.
• Change how FPU exceptions are handled. Previously they would call std::fetestexcept and directly use FE_XXX flags. This has now been decoupled properly so you can implement FPU exceptions however you want. It looks like Adding new type 'MV256W' and enabling AArch64 STP SIMD semantics. #636 was discussing similar bugs, all of which have been fixed (I think).
• Properly handle patches for sleigh without a separate Ghidra fork for PPC
• Fix a few bugs in semantics uncovered by porting to -ffreestanding and test failures with later LLVM versions
• The project now builds and runs on LLVM 15-21. There are some #ifdefs for LLVM versions, but I think it would be nice to widen the compatibility instead of only supporting LLVM 17. Due to bugs in LLVM JSON this required switching back to C++17, but the project uses no C++20 features, so I don't think this is an issue.
• Build and run on Windows (clang and clang-cl)
• Fix -fsanitize (@fvrmatteo's work)
• Properly document the superbuild dependency management solution in the README. This pattern is poorly documented, but it solves essentially all problems with CMake dependency management and keeps things flexible for integration into package managers etc.
• New GitHub Actions CI that builds dependencies from scratch (except LLVM, which is installed by the package manager)

Closes #678
Closes #718
Closes #663
Closes #573

Unfortunately splitting this up is going to be extremely tough. I can split the changes for LLVM15-21 compatibility, but the -ffreestanding changes are dependent on the FPU semantic changes and a bunch of CMake stuff. The sleigh "changes" (nothing actually changed) could be split out too, the diff just looks massive.

Note: The CI failure is something I cannot reproduce locally with any LLVM version. I suspect it is specific to the LLVM fork used in cxx-common. The docker images I use are official LLVM versions without changes, compiled with assertions enabled.

[kyle-elliott-tob]

I think this is okay based off the comments left in #625 but we are removing the explicit data dependencies. Without turning this into a naked block (which would be very brittle), not sure would could be done.

[kyle-elliott-tob]

Thanks for all the hard work over the past few days, LGTM!

Waiting on @wizardengineer for review

[wizardengineer]

LGTM, thanks again!

[cctv130]

1. I compiled using the main branch of https://github.com/LLVMParty/packages and encountered an error where the type uint32_t was not found. Adding #include <cstdint> fixed this issue.

2. For the **cxx-common-alternative** version of Remill, which version of XED does it correspond to? I encountered an error, but when using the XED built from the **main** branch of *packages*, the following cases compile successfully:

case XED_ISA_SET_AVX512DQ_KOPB:
case XED_ISA_SET_AVX512DQ_KOPW:

3. When using the cross-compilation option (-ffreestanding), I got a standard library missing error:

   fatal error: 'bits/c++config.h' file not found
   [build] 59 | #include <bits/c++config.h>
   

4. ``` clang-17: warning: no such sysroot directory: '-m32' [-Wmissing-sysroot] /Users/runner/work/remill/remill/lib/Arch/AArch32/Runtime/BasicBlock.cpp:17:10: fatal error: 'algorithm' file not found 17 | #include ```

Today, when I compiled packages on an Ubuntu Server platform, I unfortunately encountered a similar “cannot find <algorithm>” error as in GitHub Actions.
I treated the -m32 message as just a warning and ignored it, focusing instead on fixing the <algorithm> issue.
Eventually, by ensuring all standard library headers were fully available and removing the -ffreestanding flag, the build succeeded.

However, when using the -ffreestanding flag, I got other errors such as:

error: no member named '__throw_domain_error' in namespace 'std'; did you mean '__throw_runtime_error'?

Although using -ffreestanding for cross-compilation might be a good idea in theory, there currently seems to be no good way to resolve these missing standard library issues.
For users who do not want to perform cross-compilation, it might be helpful to provide a configuration switch to decide whether to enable cross-compilation or not.

[mrexodia]

I compiled using the main branch

This is not a supported configuration, so there is no reason to try this. There also is no -m32 flag anymore, so you did something wrong. Newer XED versions are not supported and cause lifting problems, so I use the same one as the original cxx-common.

[cctv130]

I compiled using the main branch

This is not a supported configuration, so there is no reason to try this. There also is no -m32 flag anymore, so you did something wrong. Newer XED versions are not supported and cause lifting problems, so I use the same one as the original cxx-common.

Can cxx-common currently run on the Windows platform ，Are there other ways to avoid relying on vcpkg

[cctv130]

I compiled using the main branch

This is not a supported configuration, so there is no reason to try this. There also is no -m32 flag anymore, so you did something wrong. Newer XED versions are not supported and cause lifting problems, so I use the same one as the original cxx-common.

Can cxx-common currently run on the Windows platform ，Are there other ways to avoid relying on vcpkg

Sorry, my English isn’t great, but I understand you now.

[kyle-elliott-tob]

cxx-common will not compile out of the box on windows. There's (currently) a few different issues, all of which our resolved by this commit. Instructions will eventually be updated in the main readme to reflect this after the merge.

[mrexodia]

You can build the remill fully on Windows with the dependencies folder (previously named cxx-common, but that was confusing), I will soon push some updates with a README explaining how to do it.

[kyle-elliott-tob]

Thank you very much again @mrexodia, a truly herculean effort that is greatly appreciated!