Quote/dumps all strings where ru_ref or call_ref take place to properly handle
arbitrary references with e.g. '$' '\n' and other tricky symbols via which it
was possible to break instantiation and to inject buildout code.

In generic mode most of the parameters have node defaults and need to be
explicitly specified.

* x/lte-multiru:
  format-json, test: Don't force ASCII
  software/nayuos: fix instantiation
  component/haproxy: Version up
  Add needed python module for Beremiz / OSIE coupler integration tests.

* master:
  format-json, test: Don't force ASCII
  software/nayuos: fix instantiation
  component/haproxy: Version up
  Add needed python module for Beremiz / OSIE coupler integration tests.

Currently, due to ensure_ascii=True default of json.dumps, we are
insisting on our JSON schemas to be ascii-only and all other characters
to be represented by \uxxxx escapes. So far this was not problematic as
all our schemas contains only ASCII characters, but upcoming
ors-amarisoft changes want to use e.g. "→" symbol:

    https://lab.nexedi.com/kirr/slapos/blob/b51f5523/software/ors-amarisoft/software.cfg.json#L15

which currently results in failure of json-schema test:

    FAIL: test_ors-amarisoft_software_cfg_json_format (slapos.test.test_json_schema.TestJSONSchemaValidation)
    ...

    First differing element 14:
    '      "title": "\\u2192  eNB/gNB | Radio Unit",'
    '      "title": "→  eNB/gNB | Radio Unit",'

And in general, in 2023 I think there is no reason to insist on our schemas to
be ASCII-only: say if one wants to describe something about "α" parameter. It
would be good to use that α character directly and seeing it in the editor,
instead of using escapes all the time.

As indicated by below stackoverflow answer "JSON spec requires UTF-8 support by
decoders": https://stackoverflow.com/a/594881/9456786 , and indeed checking
JSON specification also confirms that by default JSON decoders shall use UTF-8:

    https://datatracker.ietf.org/doc/html/rfc7159#section-8.1

This way, I think, we can switch to UTF-8 safely.

/reviewed-by @jerome, @lu.xu
/reviewed-on !1498