Currently check_sdr_busy always checks /dev/sdr0 (via `-c 0`) and
also implicitly DMA channel 0 as sdr_util help explains:

    ./sdr_util  -h
    ...
    -c device_num              select the device (default = all)
    -d channel_num             select the channel (default = 0)

This works well for ORS, which always has only single SDR board.

However for cases when there are either a) multiple SDR boards, or b)
single CPRI board, the assumption is incorrect:

- for multiple SDR boards we need to be able to specify /dev/sdrX
  instead of sdr0.

- for the case of one CPRI boards, links to different Radio Units
  attached to different SFP ports are associated with different DMA
  channels, so to test e.g. whether RU1 is being used it is necessary to
  check e.g. sdr0@0, while for RU2 it is necessary to check sdr0@1.

  I explicitly verified that for CPRI case

  a) Amarisoft kernel driver allows /dev/sdrX associated with CPRI card
     to be opened multiple times simultaneously - up to the amount of SFP
     ports = # of DMA channels, and

  b) that only DMA channels / SFP ports actually being in use are
     reported as busy by sdr_util, while the other DMA channels / SFP
     ports are not reported as busy.

  I also verified that for regular SDR board (not CPRI) using -d 0 does
  not change any verification semantic as such SDR boards have only one
  DMA channel.

-> As a preparatory step for multiRU work adjust check_sdr_busy promise
to take SDR device number and DMA channel number as arguments instead of
hardcoding sdr0@0.

For now this change is accompanied by the following change in
ors-amarisoft SR to keep it working as before:

    --- a/software/ors-amarisoft/instance-enb.jinja2.cfg
    +++ b/software/ors-amarisoft/instance-enb.jinja2.cfg
    @@ -615,6 +615,8 @@ name = ${:_buildout_section_name_}
     promise = check_sdr_busy
     config-testing = {{ slapparameter_dict.get("testing", False) }}
     config-sdr = {{ sdr }}
    +config-sdr_dev  = 0
    +config-dma_chan = 0

(posted in slapos!1458)

/cc @xavier_thompson, @Daetalus
/reviewed-by @jhuge, @lu.xu
/partly-reviewed-by @tomo
/reviewed-on !125