Ensure ABI stability with C++17/20 feature selection

[tamiko]

We currently switch between boost and standard library variants of certain classes in our base/std_cxx17 and base/std_cxx20 dynamically based on whether a C++20 preprocessor macro is set.

This has one significant issue: If the library gets compiled with say default C++14 support we will select boost variants and compile the library with that. If a user now sets C++17/20 support in a user program the user code will use the standard library variants instead. This is an issue if user and library code must be ABI compatible.

A pragmatic solution would be to revert back to our old configuration logic and simply use the DEAL_II_HAVE_CXX17 macro instead and introduce a DEAL_II_HAVE_CXX20 for the corresponding C++20 features. The of this approach is the fact that the DEAL_II_HAVE_* are "configure time" constants and do not change with whatever a user enables in their own program.

[tamiko]

@masterleinad ping

[masterleinad]

I am fine with adding the feature check macros to our configure time checks.

[bangerth]

Ugh, yes. How did we not think of that back when...

[masterleinad]

If you want me to, I can fix this later.

[tamiko]

I am happy to make the change. Pull request incoming.

[drwells]

This seems like a reasonable candidate for 9.2.1. Should we start collecting such patches?