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.

If one wants to check URLs on UNIX-sockets, there is no full URL schema
in curl for this, but the following has to be used instead:

    curl --unix-socket /path/to/socket http:/<url-path>

For this to work, one can do e.g. the following trick:

    [promise-unicorn]
    recipe  = slapos.cookbook:check_url_available
    url     = --unix-socket ${unicorn:socket}  http:/

but then generated promise scripts fails this way:

    ./etc/promise/unicorn: line 7: [: too many arguments

via quoting $URL in emptiness check we can support both usual URLs and
urls with --unix-socket prepended trick.

/reviewed-by @cedric.leninivin  (on nexedi/slapos!31)

In gitlab SR a service I need to check - gitlab-workhorse, returns 200
only when request comes to some repository and authentication backend
allows it.

Requiring access to repositories is not very good just to check if the
service is alive, and also auth backend can be not alive, and initially
there are no repositories at all. So gitlab-workhorse is checked to be
alive by pinging it with non-existing URL and expecting 403.

For this to work we need to allow clients to specify expected HTTP code
instead of previously hardcoded 200 (which still remains the default).

/reviewed-by @cedric.leninivin  (on nexedi/slapos!31)

  The final file were not a valid json sometimes as some entries '0.0.0.0' or '::' were been ignored
  and an additionalcomman was added on the wrong place.

Both SPDY an gzip_static are needed for upcoming GitLab SR:

  - GitLab uses SPDY in its https nginx configuration, and
  - prepares compiled assets in pre-gzipped form on filesystem

both modules are off by default and need to be explicitly enabled with
corresponding directives, so this should not affect already used nginx
configurations.

/cc @kazuhiko, @jerome, @gabriel
/reviewed-by @rafael  (on nexedi/slapos!30)

Those customization do not work anymore and it is preventing tests to run,
 so it should be reintroduced later in a way it works.

For upcoming GitLab SR we need Go[1] language support, because one
GitLab service is written in this language:

    https://gitlab.com/gitlab-org/gitlab-workhorse

Here we provide golang component, and helloweb-go service integrated
into helloworld SR.

The patches are based on recent helloworld & helloweb restructuring (see !23).

/reviewed-by @jerome  (on !24)
/cc @kazuhiko, @rafael, @alain.takoudjou, @gabriel, @Camata

[1] http://golang.org

For upcoming GitLab SR we need Ruby support.

We have minimal Ruby support in the form of Ruby component and
`rubygemsrecipe` recipe to install gems. However a lot of top-level
software/services in Ruby world is not released as gem and have to be
installed / worked with via Bundler[1], and for this way we do not have
an example.

Let's add such example in the form of extending helloworld SR to also
say hello to the web in both Python and Ruby via simple Ruby program
which is deployed via Bundler.

For this to happen, we need to make some preparatory changes first:

- move helloweb program(s) to own repository[2].
- modernize instance code and convert it to jinja2 to allow control structures.
- prepare instance infrastructure to support several helloweb program kinds.

and only then show how to do Ruby stuff via Bundler.

To me the effect of `software/helloworld` refactoring is good even without
Ruby part, just to improve reference material about showing how to do.

/generally-reviewed-by @jerome, @vpelletier  (on !23)
/cc @kazuhiko, @rafael, @alain.takoudjou, @cedric.leninivin

[1] http://bundler.io
[2] http://lab.nexedi.com/nexedi/helloweb