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)

Add methods for accessing individual output formats

Added some documentation ...on how to compile a GDB suitable for libgdbs / VDB.

Fix `GDBVariableObject >> updateChanged` to be an noop when thread is running ...since we cnnot query thread-related state while thread is running...

Portability: use `#digitValue` instead of `#digitValueRadix`

Portability: do not use `CacheDictionary`

Portability: guard loading of UDIS86 ...by `Smalltalk isSmalltalkX` since this is a Smalltalk/X specific code that won't work anywhere else.

Portability: transform `[...] doWhile: [...]` to `[...] whileTrue` ANSI smalltalk defines only `#whileTrue`, `#doWhile:` is stxism (yet arguably useful and more readable).

Portability: do not use Squeak computed arrays ...since Bee and others do not like them.

Portability: remove `GDBOutputFormats` pool since Bee does not realy support pools with non-literal values. Sigh.

Partability: use ANSI `#signal:` to raise an exception ..rather than St/Xism `#raiseErrorString:`.

Refactor `GDBProcess` hierarchy to improve portability Spawning and managing an OS process is tightly bound to the underlaying platform (both, smalltalk-wise and OS-wise). To improve portability and clarity of the code, rename `GDBUnixProcess` and `GDBWindowsProcess` to `GDBStXUnixProcess` and `GDBStxWindowsProcess`. This commit also includes a new abstract superclass (a `GDBLocalProcess`) for all specialisation spawning and managing a GDB process running on the same host as `jv:libgdbs` code.

Portability: get rid of private classes and make them public Namely: * `GDBMITrace::Command` (became `GDBMITraceCommandRecord`) * `GDBMITrace::Response` (became `GDBMITraceResponseRecord`)

Minor tweaks and workarounds in `GDBFrame`

Refactor configuration and autodetection of gdb executable Namely: * add new preference (`1UserPreferences current gdbExecutable:`) and actually implement `gdbExecutable:` in `UserPreferences` to make the code clearer, * refactor `GDBProcess class >> #gdbExecutable` to look at preferences and if not configured, try to autodecet path to GDB (with some magic for Windows)

Forbid blocking calls to `#send:andWait:` and: `send:andWaitFor:withTimeoutMs` from within an event dispatcher ...since it may lock. Better to fail early than let the use to debug a deadlock.

Minor cleanup and refactoring in event dispatch loop ...as preparation to factoring out event dispatching code into a separate object.

API: add `GDBFrame >> hasSymbol` and `GDBFrame >> hasSource`

Fix `GDBEventSubscription` w.r.t. uninitialized / partially initialized applications If the event observer (receiver of events) is an application (or view), the event is not processed within event dispatche loop but the pused back onot application (or view) sevent queue. However, we must be carefull since application windows may not yet be opened or fully initialized so we have to check for existence of sensor.

Add model for machine registers To access machine registers and their values, a new API method `GDBFrame >> registersWithValues` is intruced in this commit.

Fixed synchronization bug in `GDBTransientDataHolder` ...to prevent factory block being run twice if not necessary. After a quick, non-synchronized testc for sequence numbers, we have to test again in synchronized block!

Fix initialization of `GDBArch_x86` ...to handle case when package `jv:dragonfly/udis86sx` is not available. This used to raise an error which caused VDB startup failure.

Add `GDBVariable >> parent`