Provide Catch2's StringMaker specialization behind extra level of indirection

[horenmar]

Right now, users cannot change how Catch2 stringifies types that it provides StringMaker specializations for, such as float or double. This is due to the stringification priority being StringMaker<T> -> operator<< -> fallbacks (enum handler, range handler, etc).

However, users often want to customize the output, e.g. the printed precision for floating point types.

There are three ways to handle this, none of them particularly great.

• Provide customization knobs that the users can use to do what they want. This option means that there is approximately infinity work to do, and the customization options and desires can be mutually exclusive as well.
• Allow piecemeal disabling of each StringMaker specialization, e.g. CATCH_CONFIG_DISABLE_FLOAT_STRINGMAKER, or CATCH_CONFIG_DISABLE_DOUBLE_STRINGMAKER. This option adds a ton of configuration macros, which the users are already bad at using -> it is common for users to build the impl. library and their own tests with different configuration options, thus breaking ODR.
• Hide Catch2-provided stringifiers behind another layer of indirection, e.g. StringMakerInternal, used from the generic StringMaker template. This allows the users to provide specialization of StringMaker and have their specialization be used instead of ours. This is the best technical approach, but has the disadvantage of causing potentially significant compile time overhead.

Of these three options, only the last one is reasonable to implement, but we need to measure the compile time overhead first, and decide based on the final values.

[jan-moeller]

Please also consider #2298 as a relevant issue here.