need better interface to gdb debugger on Linux

oss-fuzz should improve the interface between the fuzzer harness and the gdb debugger on Linux. By using "gdb server", the `valgrind` and `qemu` projects both have a vastly better interface to gdb than oss-fuzz. For instance, `valgrind --vgdb=yes` lets you invoke `gdb my_exectuable; target remote` on another Terminal, and activates that gdb at the exact point of every detected error. Similarly, `qemu-${ARCH}-static -g 1234` lets you `multi-arch-gdb my_executable; target remote :1234` to debug any executable anywhere, with full debugger control.

As noted in https://google.github.io/oss-fuzz/advanced-topics/debugging/#debugging-fuzzers-with-gdb , `The base-runner-debug image does not have access to your sources, so you will not be able to do source code level debugging.` This limitation prevents effective debugging.

The next sentence continues `We recommend integrating your fuzz target upstream as part of [ideal integration](https://google.github.io/oss-fuzz/advanced-topics/ideal-integration/) for debugging purposes.` But the page https://google.github.io/oss-fuzz/advanced-topics/ideal-integration/ highlights serious problems:

```
For every fuzz target foo in the project, there is a build rule that builds foo_fuzzer, a binary that:

Contains the fuzzing entry point.
Contains (LLVMFuzzerTestOneInput) and all the code it depends on.
Uses the main() function from $LIB_FUZZING_ENGINE (env var [provided](https://google.github.io/oss-fuzz/getting-started/new-project-guide/) by OSS-Fuzz environment).
```
Those directions are deficient because there is no completely-worked literal example, for instance an actual `Makefile` which builds an actual C-language `printf("Hello world!\n");` main program. And please give an actual current value for `$LIB_FUZZING_ENGINE`, along with the location of copy-and-paste `OSS-Fuzz environment`. Both the name of the shell variable and an actual literal example value must be provided. Imitating a literal example is easier, faster, and more informative.

And finally, my actual experience of debugging with oss-fuzz. My project is UPX https://github.com/upx/upx . The project uses CMake, and produces both a `release` and a `debug` variant output (even before the fuzzer gets added). The `debug` build already integrates the Address sanitizer and the Undefined Behavior sanitizer of C/C++ compiled by `gcc` and/or `clang`. So UPX gets some of the benefit of the sanitizer even without OSS-Fuzz. But when the `debug` variant of UPX is fuzzed, then interactive debugging is impossible because the fuzzer (when wrapped around the existing `debug` variant) does not co-operate with gdb. In order to debug a fuzzer-reported issue, then I must guess the environment that the fuzzer set up before invoking the debugee. In the case of fuzzing UPX, I am fortunate that the name of the testcase implies the parameters that were supplied: `upx -t` or `upx -l`. Thus I can re-run UPX directly under gdb with an equivalent parameters and name of testcase, then debug interactively that way.

Therefore: the Detailed report should state explicitly the environment variables that the fuzzer set, the values of the sanitizer global variables that it sets, and the equivalent command-line invocation (`execve`) of the debugee. The fuzzer invocation should also optionally enable connection to a remote gdb, much like `valgrind` or `qemu`.

Start with the OSS-Fuzz debugging and ideal-integration pages, then inspect the base-runner-debug workflow and the UPX CMake/debug setup described in the issue. Done would require a concrete, worked integration example, explicit environment and sanitizer details, an equivalent execve invocation, and an optional remote-gdb connection path.

Written by the indexing model from the issue text.