Find a sustainable way of enabling STL assertions

There have been a few issues caught, and a few issues produced by our inability to call non-inline-defined STL functions. Some of them would obviously never work on a GPU, but things like `assert(3)` should definitely work.

In no particular order, one way or another we have had to deal with (at least) the following because of this issue

#2310
#7483
#3774
#7671

There are various workarounds to ensure this works for `assert(3)`, which in libstdc++ calls an `extern "C"` helper function. The upstream library developers have exercised their right to change the name of this function and subsequently these workarounds fail when libstdc++, libc++, glibc, musl etc change how their internal impls work.

We've discussed the issue in the above tickets, but have not come to a satisfactory conclusion on the matter. As a pragmatic hack to prevent failures on new libc versions / new host compiler versions [I changed the default cmake option for enabling these assertions to `OFF` in #7236

This ticket is to track the more long term solution, because playing catchup every time an external dependency changes its private implementation is no fun, and new users should not be alienated by cryptic compilation failures when checking out the project and building the project for the first time on a rolling distribution.

The options for solving this more generally include, but are not limited to:
- shipping our own device STL. I believe CUDA does something similar, but it is a big job and will need finesse around ABI compatibility with the host code.
- Printing a nicer error message saying I'm sorry that doesn't work for device code thankyou.
- tracking common upstream STL and libc implementations and being reactive (current approach, but not really sustainable)