Enabling threaded print of element information

[GiudGiud]

Enabling threaded print of element information

[roystgnr]

Oh, that's nasty.

I think the real fix is to make enum_to_string stop relying on just-in-time creation of those maps. I'm sure the existing code is little more than an artifact of static maps being a pain to initialize in C++98; we should have upgraded it as soon as we started requiring compilers with std::initializer_list support.

Ideally the constructor itself would be at compile-time, since there's nothing that varies from run to run about it ... but even constexpr std::vector is a C++20 thing and I don't see any constexpr std::map on the horizon. No matter; these are such small maps that just initializing a couple dozen of them in static constructors should be negligible cost, and they don't depend on any other objects so there should be no static constructor initialization order to worry about.

...

I hope? We don't have any other static objects that depend on these maps, surely? I'll need to leave a libmesh_assert(!foo.empty()) in the conversion routines to guard against that...