Added ./run_locally.sh script. The script takes one argument being the testcase
that one wants to run. The testcase is run locally. This means that some testcases that
utilize hardware resources will not run. However most if not all rfsimulator testcases
should run as in CI.

To this end, the CI python scripting framework was updated, adding --local flag which changes
the script behavior as follows:
 - overrides <node> and <srv_node> XML elements to 'localhost' so all commands are executed locally
 - Avoid running image pull, image cleanup and workspace creation steps of the scripts:
   user is responsible for that

pyflakes warns about various errors, addressed here. For cls_cluster.py,
remove (unknown) sys.exit and replace through Exception, as sys.exit()
has the unwanted effect that the CI script would stop.  Instead, raise
an Exception that would show the problem in the HTML, and ensures that
the script runs until the end.

These are the warnings flagged by pyflakes.

    cls_cluster.py:297:4: undefined name 'sys'

    cls_containerize.py:39:1: 'subprocess' imported but unused
    cls_containerize.py:41:1: 'threading' imported but unused
    cls_containerize.py:43:1: 'multiprocessing.Process' imported but unused
    cls_containerize.py:43:1: 'multiprocessing.Lock' imported but unused
    cls_containerize.py:43:1: 'multiprocessing.SimpleQueue' imported but unused
    cls_containerize.py:49:1: 'cls_cluster as OC' imported but unused
    cls_containerize.py:50:1: redefinition of unused 'cls_cmd' from line 42

    cls_module.py:28:1: 'os' imported but unused
    cls_module...

A lot of CI code is python mixed with bash, e.g.,

    ssh = getConnection(host)
    ssh.run('ls')
    ssh.run('echo')

At least some of this CI code would benefit if it was written in a
simple bash script, returning error codes and potentially other
information either through stdout/stderr or files, to the calling Python
code:

    ssh = runScript(host, script)
    # script does: ls; echo

This commit introduces the possibility to run entire scripts. The idea
is that the executor has a script (on localhost), which is either
executed locally or on a remote host. For the remote host, the script is
not copied but piped into a remotely executed bash. In both cases,
output is either returned like the Cmd.run() function with returncode
and mixed stdout/stderr, or optionally redirected into a file on the
(remote) host, which can be treated further by the Python code in later
steps.

The next commit will use "echo -e". The problem with that is that bash
and sh differ:

- in bash: this results in "a\nb" (a+newline+b)
- in sh: this results in -e a\nb (-e a+newline+b)

The problem is that by default, commands are executed through sh, which
nobody expects. Change to bash, which is likely more aligned with what
people want to use.

Add some basic unit tests to verify that Iperf/Ping work. Harmonize the
logging by only print in the "main" iperf/ping function, to avoid that
if we test with multiple UEs, the output intermixes. Also, do one common
mkdir before starting multiple pings/iperfs. Finally, harmonize the
paths so that Iperf and Ping log their files in the same place.

- Return code says if copying succeeded
- Improve handling of the recursive code paths, which copy files or
  directories recursively into another directory
- both for RemoteCmd/LocalCmd

- allow executing in background
- less logs
- no use of split()
- common implementation of legacy command()

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>