Jupyter: Change section name to instance-jupyter so as not to raise conflict in case of multiple extends

Maintain consistency with the slapOS SR format.
This SR can be hooked with other SR(ex:wendelin) and its better
to follow one way of publishing result parameters

This helps in logging up the requests made by ipython_notebook service

ERP5 kernel basic info/workflow:

1. User enters code on notebook cell and executes
2. Code is sent to kernel via websockets
3. Kernel sends request to ERP5
4. Code is executed by ERP5 and the result is returned back via request.
5. Result is received and rendered on the notebook frontend.
6. Other message formats such as error and status are also conveyed by the Kernel.

IPython Notebook: Explicitly add environment variable around wrapper and use ipython directory inside instance in env

IPython Notebook: Add dynamic-template-base section for common jinja related file section and extend them with this section

IPython Notebook: Add download-file-base section which would be extended by sections requiring common usage

Use spinal-case('-' separated) instead of snake_case('_' separated) in section names.

In case there are errors when creating cluster / setting up its
configuration files, currently we leave pgsql database left
half-installed and next time instantiation runs do not do anything,
because os.path.exists(pgdata) is already true.

I've personally hit this situation via providing ipv4 and ipv6
parameters as strings and the recipe wanted to do `ipv4.join(ipv6)` but this
works only for sets and raises for strings.

What is worse is that the above error becomes hidden in our default
setup, because webrunner tries to do instantiation _several_ times, and
on the second run instantiation succeeds, because pgdata directory
already exists and recipe thinks there is nothing to do _and_ webrunner
already removed instance.log from previous run.

So do not hide errors, and if we see there are problems, remove the
wholly created pgsql database directory.

/cc @kazuhiko, @jerome
/proposed-for-review on nexedi/slapos!29

If the list of families does not change, their ports must not change, and it's
wrong to get this by relying on CPython implementation details. Even if we
automated the update of frontends with new urls, this couldn't be done
atomically and we'd get random failures.

Currently, frontends are only updated manually so we also want to minimize
changes when families are added/renamed/removed. By sorting alphabetically,
we have something predictable. Of course, this does not cover cases like the
following one:
- before: A, B, C
- after: A, C
Even if we added a 'port-base' parameter for the balancer, the port would
change for one of the 2 families.

We have no need for the moment, but we could go further with an optional list
parameter to choose the order, and a special value to skip ports. Another
option is to use publish-early but it's more complicated to implement and
we lose everything when we reinstanciate.

The sort in haproxy.cfg.in is for the stats page.

that is a long-deprecated syntax and removed in haproxy 1.6.

version up : OpenSSL 1.0.2e, including CVE-2015-3193, CVE-2015-3194, CVE-2015-3195 and CVE-2015-3196.

https://www.openssl.org/news/secadv/20151203.txt

From https://golang.org/doc/devel/release.html#go1.5.minor:

    go1.5.2 (released 2015/12/02) includes bug fixes to the compiler,
    linker, and the mime/multipart, net, and runtime packages

/reviewed-by: TrustMe