GDB: introduce a "ready to use" check when instantiating a GDBServer

It turns out that, in some conditions, such as when immediatelly trying
to communicate with a gdbserver process after it is executed, results in
failure.

The reason seems to be that gdbserver itself takes "some" time between
being executed and binding to the TCP port.

While prototyping GDB remote client in pure Python, this kind of race
condition was found.

Now, by default, there will be a 2 seconds timeout and a explicit check
for gdbserver's "ready to use" status.

Changes from v1:
 * added documentation for the __init__ method

Signed-off-by: Cleber Rosa <crosa@redhat.com>
GDB: add implementation of remote protocol

GDB talks to targets via a so-called remote protocol. These targets
can be things like gdbserver, ROM monitors on specific hardware boards,
or applications that implement the same protocol.

One noteworthy example of application is QEMU, which implements some
basic GDB Remote commands and also a few extenions of its own.

This initial implementation allows connecting to the remote target,
sending commands and receive results. The API can certainly grow later
based on demand.

Changes from v1:
 * Fix a typo in the REMOTE_MAX_PACKET_SIZE comment

Signed-off-by: Cleber Rosa <crosa@redhat.com>
GDB: use gdbserver --server-sdtderr option if available

A new command line option is being added to upstream GDB. This new
option allows gdbserver's own stderr (but not its inferior process
stderr) to be redirected to another file.

If that feature is available on the about to be used gdbserver, then
let's make use of it. This redirects its stderr to /dev/null, because
avocado itself has no real use for gdbserver's own stderr output.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
Merge pull request #280 from clebergnu/gdb_remote_v2

GDB remote protocol support [v2]
Merge pull request #281 from clebergnu/gdbserver_stderr_v2

GDB: use gdbserver --server-sdtderr option if available