Add triggerable C/C++ debugging

[AlbertoEAF]

Motivation

This PR allows triggering a debugger on the C++ land from the target language (C/Python/Java/...). This can be very helpful during development and debugging of the core C/C++ codebase. For instance, it's possible to debug Java and C++ at the same time.

Changes

Two macros are provided:

• GDB()
• GDB_ON_TRIGGER()

The first triggers gdb/ddd. The second is the same but only triggers in case the method trigger_gdb() in utils/gdb.h was called before.

These macros only generate code when LGBM is compiled with -DUSE_DEBUG=ON, otherwise they add up no overhead.

Every method in the C API now starts with a GDB_ON_TRIGGER(), meaning all methods in the C API can be debugged promptly.

The debugger will kick in and the program will wait until signal_gdb_attached() is called by the user.
This will then unlock and resume the program execution.
In case the debugger fails to kick in, it's easy to attach with gdb --pid=<target_pid>, and the program will periodically print the target pid until signal_gdb_attached() is called.

[AlbertoEAF]

Hello @guolinke @imatiach-msft @StrikerRUS @jameslamb ... :),

I just made this code for we were having very difficult to undrestand bugs in the C++ patches we were developing, specially when calling the core code from Java. This was crucial to find what was going wrong.

Do you think this could be useful too? Suggestions welcome :)

Maybe official documentation should be added as well for developers, in case they want to trigger debugger this way?

[jameslamb]

Thanks very much for taking the time to write this up and share it @AlbertoEAF ! I'm interested in considering it, especially if it can be done in a way that adds 0 new required dependencies, compile time, object size, or portability issues as long as that flag is passed.

But right now, most of the project's CI jobs are failing on this branch. If you're open to working on getting those tests passing, I'll commit to testing this out locally after, to see how helpful it is for debugging. But until we see those CI jobs passing, it's hard to evaluate exactly what possible issues this propose change might cause for users.

[StrikerRUS]

I'm sorry, I'm not able to provide a thoughtful review for this PR, but I find it quite useful.