Fixed `GDBThreadGroup >> #executable` for case where executable ir not known (reported) such as when debugging bare-metal code or the target does not report it (may happen, for example wine's winedbg GDB proxy does not report executable names.

Fixed `GDBVariableObject >> #duplicate` for children od dynamic varobjs For children of **dynamic** varobjs we cannot duplicate them just by evaluation their "path" (fully rooted expression) since they have none. Thus, we first duplicate the parent and then return child of the just duplicated parent at corresponding index. It'd be nice if GDB supports that via, say, `-var-clone` command, but at the time of writing, there's no such support.

Added support for dynamic varobjs

Pass MI trace in the exit event This allows users to inspect the trace when GDB terminates abnormally (i.e., crashes).

Added support for breakpoints with multiple locations ...such as breakpoints on inlined functions.

Fixed `GDBDebugger >> directories` to work on Windows

Removed workaround for GDB bug 18077 ...which has been fixed in GDB 7.11. https://sourceware.org/bugzilla/show_bug.cgi?id=18077

Fix: do not try to retrieve executable path if inferior is running and async mode is available ...since it would block.

Fix: initialize debugger features early during initialization The frontend or `stx:libgdbs` may need to query features to conditionally perform some logic, however, if the target does not support async mode (such as Windows), it would block. The GDB documentation says: Whenever a target can change, due to commands such as -target-select, -target-attach or -exec-run, the list of target features may change, and the frontend should obtain it again. The problem is, however, that on a target that does not support, once `-exec-run` is issued, the inferior runs so GDB does not accept any commands until inferior stops. To workaround this until a better solution is found, initialize target features on first stopped event and until initialized, use "default natives features", a hard-coded set. Ugly, but we should move on.

API: improved `GDBFrame >> #file` ...to try to resolve relative paths using source directories. GDB should do that but somethimes it gets confused so try ourselves in that case.