cli_monitor: add a 'gdb' command

This patch adds a 'gdb' command to 'cli_monitor', which makes it possible
to debug an application with GDB.

The command works similarly to the 'start' command, but instead of
starting the subsystem binary directly, an 'init' subsystem gets
started, which then starts 'terminal_crosslink', 'noux', GDB and
'gdb_monitor' (which starts the application binary as its target).

So, for the 'gdb' command to work, these additional components need to
be available, too. 'terminal_crosslink', 'noux', 'gdb_monitor' and the
file 'gdb_command_config' are expected to be ROM modules. The Noux GDB
client needs to get mounted at '/bin' in Noux and the target binaries need
to be available as ROM modules (loaded by 'gdb_monitor') and also mounted
at '/gdb' in Noux (loaded by the GDB client).
Additionally, the source code of the target application can be provided
at '/gdb/src/ in Noux. How the Noux mountings get established can
be configured in the 'gdb_command_config' file. The default configuration
in 'os/src/server/cli_monitor/gdb_command_config' mounts GDB from a tar
archive named 'gdb.tar', the GDB target binaries from a tar archive named
'gdb_target.tar' and the target source code from a tar archive named
'gdb_target-src.tar'.

The patch includes an 'expect' include file (ports/run/noux_gdb.inc)
which provides functions that help to create those tar files:

- 'create_gdb_tar' creates a tar archive for the 'gdb' client
- 'create_binary_tar' creates a tar archive for the target application
- 'create_source_tar' creates a tar archive for the source code of
  the target application
- 'create_binary_and_source_tars' is a convenience wrapper for the previous
  two functions

The patch also includes an example run script
(ports/run/noux_gdb_dynamic.run).

The 'gdb' command supports the following command line options:

- --ram: the initial RAM quota provided to the whole subsystem
         (including the GDB-related components)
- --ram-limit: limit for expanding RAM quota
- --gdb-ram-preserve: the RAM quota that 'gdb_monitor' ahould preserve
                      for itself

Fixes #928.
GDB monitor: test the 'set var' and 'call' commands

Fixes #930.
init: don't call Rom_session::dataspace() twice

In general, requesting a dataspace from a server twice is no good
idea. The server might react in a unrecoverable fashion. E.g. the rom_fs
service always throws away the corresponding dataspace from the first call
of dataspace(), and constructs a new one.
l4lx: extend l4linux_dynamic run script

Add a graphical scenario to the cli_monitor setup, which includes
a more complex GDB debugging scenario.