gdb-stacktrace is incorrectly presented as a debug option

Description

While the debug options are currently documented to be only for debugging and that they should not be used in production. However, the debug=gdb-stacktrace is especially useful in production scenarios where SystemD Watchdog may occur due to various reasons. Before 23.08, the only way to detect the real cause of the watchdog timeouts would be to use debug=gdb-stacktrace to produce multi-threaded stacktraces.

Either the debug parameters should be documented or the debug=gdb-stacktrace functionality should be moved out into its own parameter.

Design

The need for debug=gdb-stacktrace is only know when the problem has already appeared once. This is usually too late and if GDB is available on the system, it would be better to use it even if debug=gdb-stacktrace is not configured. Documenting the debug options is not ideal as they're not intended to be used in production. Separating out the gdb-stacktrace into its own parameter would solve this but since it's always preferable to use GDB for stacktrace generation whenever it's present, it's better to behave as if debug=gdb-stacktrace is always enabled.

Implementation

Detect the presence of GDB on MaxScale startup and if it's present, use GDB for stacktrace generation. The old debug=gdb-stacktrace will then unconditionally enable the GDB usage even if it wasn't detected at startup. If the stacktrace generation with GDB fails, the internal stacktrace generation code is used instead.