This causes various runtime failures, as reported in #168628.

This reverts both #165223 and #167779

Fixes #167991

Otherwise, we end up using whatever system-provided compiler runtime is
available, which doesn't work on macOS since compiler-rt is located
inside the toolchain path, which can't be found by default.

However, disable the tests for compiler-rt since those are linking
against the system C++ standard library while using the just-built
libc++ headers, which is non-sensical and leads to undefined references
on macOS.

Add a new CMake variable, `LIBCXX_ASSERTION_SEMANTIC`, that largely
mirrors `LIBCXX_HARDENING_MODE`, except that it also supports a
special value `hardening_dependent` that indicates the semantic will be
selected based on the hardening mode in effect:
- `fast` and `extensive` map to `quick_enforce`;
- `debug` maps to `enforce`.

Instead of having one large Dockerfile building multiple images with
relatively confusing inheritance, explicitly have three standalone
Dockerfiles each building one image. Then, tie the three images together
using the docker-compose file which explicitly versions the base image
used by the Android and the Github Actions images.

The llvm-mingw toolchains defaults to `_WIN32_WINNT=0x601`, so this
configuration is covered by our CI build matrix.

Since 1939eb3dc2330af6fb9609a7c3bd5276e127c9ce, std::filesystem is
enabled by default in MSVC builds too.

Implemented in LLVM15:
https://github.com/llvm/llvm-project/commit/e53c461bf3f0feebb4fd6b43e05a0047f8edb945

This LWG concerns`lazy_split_view` despite the outdated title.

Closes #104320

# References

- https://wg21.link/LWG3505
- https://wg21.link/range.lazy.split.outer

Co-authored-by: Hristo Hristov <zingam@outlook.com>

Resolves #148131

- Unlock `std::optional<T&>` implementation
- Allow instantiations of `optional<T(&)(...)>` and `optional<T(&)[]>`
but disables `value_or()` and `optional::iterator` + all `iterator`
related functions
- Update documentation
- Update tests

Per https://github.com/cplusplus/draft/pull/7505, LWG approved P3355R2
and the differences between P3355R1 is subsequently applied. So it seems
better to refer to P3355R2.