Update target features from `=target-connected event` ...so feature list is up-to-date

Fix DNU in `GDBMITraceViewer` when debugger terminates

Add `GDBDebugger >> #waitForAllEventsProcessed` and `#waitForAllCommandsProcessed` These methods are meant mainly for synchronization in tests, NOT for normal user code. Uses should avoid calling these.

API: add `GDBDebugger >> getParameter:` and `setParameter:to:` ...to get / set GDB internal parameters such as prompt. The only complication here is that when a parameter is set by MI `-gdb-set` command, the `=cmd-param-changed' notification is not sent. This may or may not be a GDB bug. To make this transparent to `libgdbs` clients, intercept all `-gdb-set` commands and when sucessful, emit the event manually. This way, client may rely on value change notification (`GDBCmdParamChangedEvent`) to detect changes.

Fix synchronization issue in `GDBThreadGroup >> onThreadSelectedEvent:` ...which may be invoked when thread is actually still / already running. This check is bit ugly and strictly speaking not correct (meaning race-free). For now, it would do. We need to think on how to deal with that better on a general level.

Use inferior PTY only if supported ...i.e., when running GDB locally on UNIX-like systems. Note, that the fact that `libgdbs` is running on UNIX-like system does not necessarily mean PTYs can be used - GDB still can run on remote machine via SSH.

Add class for new MI command `-complete`

Add new API `GDBDebugger >> #hasCommand:` to test support for particular MI command Internally this uses GDB's `-info-gdb-mi-command`. Results are cached to avoid uneccessary round-trips upon repeated calls.

Add support for arbitrary (shell) command to launch GDB. Until now it was only possible to specify GDB executable. In some cases however it is useful to be able to specify whole command including parameters - passing --data-directory or tunneling GDB through SSH, for example. To support this, a new setting, #gdbCommand: has been introduced making old gdbExecutable: obsolete. The specified command is NOT passed to shell, however. Instead, it's parsed the same way shell (or `cmd.exe` on Windows) would do it and then passed to `exec()` (`CreateProcessEx` on Windows). This is to avoid shell inkering with input/output stream - we need to handle them ourselves.

Renamed `GDBStXWindowsProcess` to `GDBStXSimpleProcess` ...as it may be used in more scenarios than on Windows. For example, it can be used to spawn gdb remotely using SSH (handy in cases there's no gdbserver implementation for remote machine)