SlapOS provides to each partition dedicated TAP interface, so that an instance
could organize internal networking. In practice this is used by KVM software
release and here in ors-amarisoft, where we feed to eNB such TAP interface for
CPRI-based radio unit so that eNB, in turn, could provide access to CPRI
Control and Management channel via provided TAP.

However there is a problem: SlapOS provides only one TAP interface per
instance, while we need to have one TAP for each Radio Unit.

-> Solve this problem by creating TAP "subinterfaces" per each RU ourselves.

The interfaces we create are full TAP interfaces, just we name them with prefix
based on main interface, and we allocate only part of address space of sole
SlapOS TAP to each subtap. For example if SlapOS provided us slaptap16 with
2401:5180:0:66:a200::/71 IPv6 range and we want to split it for 2 radio units,
we'll be splitting it into 3 regions as follows:

    slaptap16: split 2401:5180:0:66:a200::/71 by 2
    preserve         2401:5180:0:66:a200::/73
    -> slaptap16-1   2401:5180:0:66:a280::/73
    -> slaptap16-2   2401:5180:0:66:a300::/73

Here we preserve 2401:5180:0:66:a200::/73 for usage on original slaptap16, and
we create slaptap16-1 and slaptap16-2 with correspondingly allocated address
range subparts for the RUs.

The splitting is done easily but depends on having networking administration
capability to be able to work. We solve this with employing
/opt/amarisoft/setcap, which we already use for dnsmasq, and with compiled
trampoline program because setcap does not really work directly on scripts.

To avoid hard dependency on having network capability rights, we fallback to
using regular SlapOS slaptap in case there is only one RU.

ru/lopcomm/* and enb.cfg are adapted straightforwardly, but dnsmasq adaptation
is left to a later step not to mix everything into one pile.

NOTE that relying on setcap is not a good in the long term and should be
     reworked once SlapOS is improved to provide ability for instances to
     request several TAP interfaces. Please see discussion at
     !1471 (comment 194356)
     for details.

/cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
/reviewed-on !1471