[NOT FOR MERGE] GDB stdout/stderr support

OK, the `[NOT FOR MERGE]` prefix should point out the not so good news.

After some experiments to give a process debugged under GDB a proper `result.stdout` and `result.stderr`, two approaches were tested:

1) Redirect the inferior process stdout with GDB's help

The GNU Debugger documentation documents a `run` command syntax in which one can redirect the output to a file. Actually, this feature is even more robust than documented, and supports separating the `stdout` stream to yet another file.

The prototype and validation of this feature is so straightforward that did not require any significant code, just adding the `> /path/to/stdout_file` and `2> /path/to/stderr_file` was sufficient. The idea was to collect that content and make it available as part of the `CmdResult.stdout` and `CmdResult.stderr` members, just like it happens with standard `avocado.utils.subprocess.SubProcess`.

The problem is that GDB does not support that when running on a remote target (even if running on the local system). It silently ignores the redirection on the remote target.

2) Open (create) a new pseudo terminal device and sets the debugged process terminal to that.

This would also allow, besides output, *proper input handling* if a user ever needs to interact with an application like that. This approach actually worked during the prototype, and let to the implementation of the code attached here. 

But, during the integration of the `avocado/gdb.py` module code (the avocado gdb api) with the transparent execution of processes (which adds a `gdbserver` into the mix) it proved to not work again, and again due to a GDB limitation. Simply put, remote targets (even if they're on the same macine) and (local) terminal device assignment is incompatible. 

Maybe this is the current status, or maybe this is not possible at all.

IMHO, the use case that avocado has is something new as far as GDB is concerned. My suggestion would be to try  to get the features needed in upstream GDB. Whether this is a minor task that GDB developers themselves will respond to, or a major task that we'll need to invest in is yet to be seen.

@adereis @lmr @ruda any comments about this?