When ld version is too old (Debian 7 comes with version 2.2 which is too
old), golang testsuite fail with:

binutils_test.go:237: SourceLine for main: expect [{main /tmp/hello.c 3}]; got [{main  0}]

see also https://github.com/golang/go/issues/26584

We explicitly use gcc 8.2, but what we need is gcc > 5.5 because of
https://github.com/golang/go/issues/24046
When 8.2 (or newer) becomes the default SlapOS gcc, there should be no
problem in dropping the explicit version and using ${gcc:location} here.

This version is compatible with the default firefox (52)

geckodriver is also required

New software release, selenium server, which expose a http server to which clients can connect using [`webdriver.Remote`](https://selenium-python.readthedocs.io/getting-started.html#using-selenium-with-remote-webdriver) and then use standard webdriver API to control the browser.

The server is made of :
 * the "hub" to which webdriver connects
 * a Xvfb server
 * some nodes, for different browsers:
   * Firefox 52
   * Firefox 60
   * Chrome 69
 * an IPv6 https frontend, exposing the admin interface and the hub. Note that python's webdriver binding before 3.14.0 refuse to connect to a hub with a non verified SSL certificate, so for now clients must either use the published `backend-url` (which is IPv4) or use a version of selenium eggs >= 3.14. In the future we'll see how [caucase](https://lab.nexedi.com/nexedi/caucase/) can solve this. Also, this behavior might also change with future version of selenium, because it's wrong that it does not verify SSL certificates.
 * a ssh server, to which you can connect to establish a ssh tunnel with port forward and register more nodes to the hub. This can be used to connect a browser running on your desktop and see the test running, run unsupported browsers, maybe also [appium](http://appium.io/docs/en/advanced-concepts/grid/) to run tests on mobile. This is a kind of "extra feature" that seems working, but I'm not sure we can support it.

To achieve this, we had to :
  * update Xorg components and build gtk with a X11 gdk backend  to be able to run firefox 60. Updating xorg/gdk also fixed a bug in firefox 52, before this, firefox 52 was not able to get the screen size and ` window.screen.width` was 0. Now firefox 52 can get the screen size properly but resizing window does not work.
  * update chrome 69 and fix a few missing `$LD_LIBRARY_PATH` in the wrapper.

Everything seems working, including taking screenshots, uploading files and resizing window - except resizing window does not work on firefox 52.

See the included test suite for some example usage. Basically it's same as what we're doing today, but instead of:

```python
driver = webdriver.Firefox(path_to_firefox)
```

we use:

```python
driver = webdriver.Remote(
   command_executor='http://127.0.0.1:4444/wd/hub', # the url or backend-url parameter published by the instance.
   desired_capabilities={
      'browserName': 'firefox', # or chrome
      'version': '60', # or don't set a version if you want any version (browserName, on the other hand, is required)
   })
```


/reviewed-on nexedi/slapos!420

Change jstestnode arguments to accept the [desired capabilities](https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities) as a JSON object, so that we can run jstestnode tests on any selenium server ( the target being !420 ), not only saucelabs.

This MR also introduces some JSON schema for instance parameter.

/reviewed-on !429

https://www.theia-ide.org/

/reviewed-on nexedi/slapos!417

@tomo @rafael if you have any review on this (should be ok as its kind of same commit than last update one, but well)

/reviewed-on nexedi/slapos!433

Improves 57bdf689 by having stored and
expected values stable across runs.

Also assertion is done with {hash} instead its real value, as it has no
meaning to test user.

this is a followup of nexedi/slapos!427

/reviewed-on nexedi/slapos!431

Cloud & Desktop IDE https://www.theia-ide.org/

This version is inspired from "theia-full-docker" from
https://github.com/theia-ide/theia-apps so it includes all extensions.
Many language servers are missing in this version (basically only go,
typescript and python language servers are installed).
PHP extension is not even installed.

Previously it was required to put \ into multi-entry gowork.install,
because the way it was processed was to directly pass it into bash
command, and if \n were there the command was cut by bash and the
trailing was considered as another command.

We can avoid that by explicitly processing \n in gowork.install and
translate it to just ' '. This helps people because now gowork.install
becomes just a regular multiline buildout entry, similar e.g. to
gowork.cpkgpath et all.

Here is one example where it helps:

jerome/slapos@95c45fe0 (comment 68408)

/reviewed-by @jerome
/reviewed-on nexedi/slapos!430

Since f427842b some software releases has been
found to be without pinnsed eggs for GitPython dependency.

/reviewed-on !432

This is a backward incompatible parameter change.

for example to run on saucelabs, instead of:
  {
    "target": "iOS",
    "target-version": "11.3",
    "target-device": "iPhone Simulator",
    "target-browser": "Safari",
    "appium-server-auth": "username:auth-token",
    "test-suite" : "renderjs",
    "remote-access-url": "https://softinst1234.host.vifib.net"
  }
we now use:
  {
    "target": "selenium-server",
    "desired-capabilities": {
      "platformName": "iOS",
      "browserName": "Safari",
      "platformVersion": "11.3",
      "deviceName": "iPhone Simulator"
    },
    "server-url": "https://username:auth-token@ondemand.saucelabs.com/wd/hub",
    "test-suite": "renderjs",
    "remote-access-url": "https://softinst106116.host.vifib.net"
  }

To run locally empty parameters are still OK.

/reviewed-on nexedi/slapos!427

/reviewed-on nexedi/slapos!413

using husky + lint-staged

There was two sections writing the file `bin/monitor-httpd` which led to some problems when running things

/reviewed-on nexedi/slapos!426

/reviewed-on nexedi/slapos!409

/reviewed-on nexedi/slapos!411

/reviewed-on nexedi/slapos!410

  Sticky computer on kvm cluster, will make the requester (root instance on this case), request
  the children on the same computer as itself.