testkit-backend: Add support for testing driver in browser (#798)

The initial implementation of the `testkit-backend` is NodeJS only which is not an issue for the time being. However, It starts to be problematic  with new features being implemented test driven using `testkit` as the source of tests. First, the time for run all the suite increased a lot with the number of tests added and the need of keeping the some integration tests to not let browser uncovered. Second, the driver running in browser was not being tested with the same rigour as in Nodejs.

The following changes were done with the intent to support testkit tests in Browser.

### Refactoring 

The logic of reading and writing in the socket, call the handlers and parse the messages were mixed in the Backend class. This makes difficult to add different protocols, channel implementation or controllers to the backend.

The goal of this change is separate this three concerns in `Channel`, `Controller` and `Protocol` with the `Backend` class as the glue between these concepts. New implementations of the `Controller` could enable this backend to test the driver running in the browser without have to change the logic of parsing the messages between testkit and testkit-backend, for instance.

### Supporting Browser

The first step for supporting testkit in browser was creating a `web socket` server to redirect the requests to a client. `RemoteController` is the class responsible for it, it acts like a proxy redirecting the requests and responses. In the other side, `WebSocketChannel` is responsible for managing the messages exchanges between `browser-backend` and `nodejs-backend` in the browser side. 

The `main` function glued everything together using env variables for selecting the correct channel and controller. 

A bit more of structure had to be taking in place for bundle testkit for running in browser. The bundle is supported by `rollup` and defined in `rollup.config.js`, this runs during the build and the outcome is stored in `public/index.js`. The following env variables are defined during the browser build to enforce the correct configuration:
* `TEST_ENVIRONMENT` = "LOCAL"
* `CHANNEL_TYPE` = "WEBSOCKET"
*  `BACKEND_PORT` = `WEB_SERVER_PORT` (or `8000` if nothing is set in `WEB_SERVER_PORT`)

The last thing done during the browser build process is done by some replacements done in the `package.json`, the `./src/controller/remote.js` and `./src/channel/socket.js` are replaced by their interfaces since the some modules used in this files are really tricky to support in browser and they are not need at browser. 

After we have the browser bundle done, we need to server it. It is done by the `RemoteController` as well.

At this point, you can run `TEST_ENVIRONMENT=REMOTE npm run start-testkit-backend` and open your favorite browser in `localhost:8000` for running testkit tests in browser.  

### Glue everything in Testkit

Last but not least, the testkit scripts were adapt to use the environment `TEST_DRIVER_BROWSER` to decide if the tests should be run in browser and in nodejs. Integration tests were segregated for running only the ones needed for the environment under tests. 

`backend.py` is responsible for configuring correctly the backend using the env-variables and also for starting a headless browser with the browser-backend url.  

### IMPORTANTE NOTE

**This version doesn't support TLS_TESTS and STUB_TESTS since the mock servers doesn't support websocket yet**

Author: bigmontz

packages/testkit-backend/.gitignore

@@ -0,0 +1 @@
+public/index.js