In MultiRU we are going to have generic software with flexible configuration
and many features + ORS software, which wraps the generic part, adds ORS
specific features, and translates simple ORS schema to generic ones.

Let's first move ORS-specific bits to dedicated place as a preparatory step for that:

- add software-ors.cfg . In the future software-ors.cfg will be the entry point
  for ORS mode, but for now it is only a place from where software-ors-* extend from.

- add instance-ors.cfg . We move ORS-specific code from instance.cfg here and
  set it to use instance-ors-enb.jinja2.cfg when instantiating enb/gnb.

- add instance-ors-enb.jinja2.cfg . This pulls ORS-specific code from
  instance-enb.jinja2.cfg + instance-gnb.jinja2.cfg and wraps them with ORS
  context built by instance-ors.cfg

- in the templates the way to see whether it is ORS or not, and if yes, to access
  ORS parameters is changed: now it is always via checking `ors` object, which
  can be either False for non-ORS mode, or dict for ORS mode, and if it is dict
  the keys inside that dict are ORS specific properties, e.g. ors['one-watt'].

  This adjustment is handy to organize ORS mode extension from generic with
  generic setting `json ors false` in the context, and ORS mode undoing that and
  setting ORS context properly. I think the code also reads more clear this way, i.e. with

 	{%- if one_watt == "True" %}

  changed to

	{%- if ors['one-watt'] %}

  because in the second variant it is clear that one-watt is a property of ORS.

The rendered configs for enb.cfg and gnb.cfg stay unchanged.

/cc @jhuge, @lu.xu, @tomo, @xavier_thompson, @Daetalus
/proposed-for-review-on nexedi/slapos!1522
/reviewed-by TrustMe