feat: Add command-line option to control developper information output in diagnostic messages

[MelReyCG]

This PR introduces a new command-line option to control diagnostic log verbosity in GEOS. The goal is to reduce the verbosity of logs by default while still providing detailed developer information when needed.

New option:

-d, --diagnostic-info-level,  Diagnostic message information level:
                                0 = (default) basic information,
                                1 = developper information (source file, stack-trace) for errors only,
                                2 = developper information for warnings & errors

For an error, -d 0 would give:

***** ExternalError
***** Rank 4
***** Message from Signal (detected from Signal Handler):
Floating point error encountered:
Unknown reason.

... and -d 1 would give:

***** ExternalError
***** Rank 4
***** Message from Signal (detected from Signal Handler):
Floating point error encountered:
Unknown reason.

***** StackTrace of 15 frames
  - Frame  0:  /lib64/libc.so.6 
  - Frame  1:  void geos::isothermalCompositionalMultiphaseBaseKernels::internal::kernelLaunchSelectorCompSwitch<int, geos::isothermalCompositionalMultiphaseBaseKernels::GlobalComponentFractionKernelFactory::createAndLaunch<RAJA::policy::sequential::seq_exec>(int, geos::ObjectManagerBase&)::{lambda(auto:1)#1}>(int, geos::isothermalCompositionalMultiphaseBaseKernels::GlobalComponentFractionKernelFactory::createAndLaunch<RAJA::policy::sequential::seq_exec>(int, geos::ObjectManagerBase&)::{lambda(auto:1)#1}&&) 
  - Frame  2:  geos::CompositionalMultiphaseWell::updateGlobalComponentFraction(geos::WellElementSubRegion&) const 
[...]
  - Frame 11:  geos::GeosxState::run() 
  - Frame 12:  main 
  - Frame 13:  __libc_start_main 
  - Frame 14:  _start 
*****

The last option, -d 2, also enables the output of stack trace and source file for warnings.

Stack traces and source files are still included in the YAML output through the -e option, but now users can control the presence of developper information in the log through this new -d option.

[arng40]

You mean "DiagnosticInfoLevel"

[arng40]

remove

[arng40]

A suggestion, typeToString may be redundant with EnumString.
You could use EnumString instead of typeToString by moving this enum to a separate class.

[MelReyCG]

I just renamed ErrorLogger::toString(), but yes I can refactor if this function is not useful.
It is not in a class right?

[MelReyCG]

Ok, no I'm not able to do this with enum-strings. It is to avoid circular header dependancy.

[arng40]

Maybe put MsgType in another file, it will avoid the circular dependency

[arng40]

remove