oml: Use the queue for the release handling of a channel
oml: Use the queue for the release handling of a channel

There are three new commands. There are two markers and a deactivate
command. The markers are used to wait until all previous commands are
executed and then to decide if the SAPI needs to be released at all.

When asked to release the SACCH the marker will be queued, then on
execution of the marker the SACCH in Up-/Downlink will be released.

For the RF Channel Release we use another marker, when the marker is
executed we check all the SAPIs we want to release. It is possible that
the queue looks like this:
   (SACCH_REL_MARKER is done) REL_MARKER, SACCH DEACT, SACCH DEACT

This could happen if a BSC sends SACCH Deactivate and RF Channel Release
at the same time. We deal with issue by changing the SAPI state to the
REL_REQ state and check_sapi_release will not ask for another release. So
after the execution the queue will look like this:

  SACCH DEACT, FACCH DEACT, TCHF DEACT..

This code does not check that all allocated SAPIs are released. The
lchan_deactivate_sapis could be changed to go through all sapis_dl
and sapis_ul to fix that.

The normal flow should now be:
1.)  lchan_deactivate
2.)  Check if the queue is empty then go to 4
3.)  REL_MARKER is executed and lchan_deactivate_sapis is called
4.)  For all SAPIs to be released, check if they are allocated and
     then schedule a CMD_DEACTIVATE. If there is an error remember
     something went wrong but continue.
5.)  Once all commands are executed send the channel release ack.

For the release markers we need to be careful as they might not schedule
any work. E.g. if the BSC sends two SACCH DEACTIVATE the second marker
will not generate any release requests and we should proceed with the
next command. Make sapi_queue_command return 1 in case the command has
been directly executed. So a queue like SACCH_REL_MARKER, LOGCH will
result in LOGCH, SACCH DEACT Rx, SACCH DEACT Tx but a 0 will be returned
and the sapi_queue_next will then call sapi_queue_exeute again.

NITB has been modified to trigger these corner cases more easily.
* Do not send IMM.ASSIGNMENT for some timeslots to go through the
error path
* Issue multile SACCH deactivates in the normal release mode
* Send rsl_chan_mode_modify_req before the SACCH DEACT and also when
the RLL is being released.

osmocom/osmo-bts,shimaore/osmo-bts,osmocom/osmo-bts,telenoobie/osmo-bts,osmocom/osmo-bts,shimaore/osmo-bts,shimaore/osmo-bts,telenoobie/osmo-bts,telenoobie/osmo-bts,geosphere/osmo-bts,geosphere/osmo-bts,shimaore/osmo-bts,telenoobie/osmo-bts,geosphere/osmo-bts,geosphere/osmo-bts