ska-tango-base improved command handling visibility, broader support for command restart and adminMode=ENGINEERING

1) Done and released with ska-tango-base 0.20.1 (REL-1260):   Add attributes: commandedState and commandedObsState.
The attribute value should be updated:

• during initialization (from the default, probably hard-coded, or alternatively loaded from a configuration file) and
• when a command that triggers state transition is received. In the case where the command first triggers transition to a transient state, the commanded state is the next stable state (example: when AssignResources() is received, the commandedObsState=IDLE).
  When the current state/obsState is not the same as commanded state/obsState and command is not in progress the Device should raise warning or alarm (depending on the severity).
  The attribute commanded state/mode should be added in the cases where state/mode transition is triggered via a command while the current state/mode is determined based on aggregation or on the reported state of the actual device.

2) Done and released with ska-tango-base 0.20.1 (REL-1260): Add attribute longRunningCommandInProgress.

This will enable a client to determine which commands are being executed, if any.
When there is no command in progress it returns an empty list.

The behaviour of this attribute is changing with the ska-tango-base 1.0.0 (REL-719) release to that described above.  For the ska-tango-base 0.20.1 release, the attribute always returned a list of two strings (a slot for Abort + one other command), using empty strings to represent no command in progress.

3) Done and released with ska-control-model 0.3.4 (REL-1252): Observing State machine update: command Restart() should be allowed (accepted and executed) when obsState=EMPTY. This provides a mechanism to restart (re-initialize) a device and return the device (and its subordinate components) to the operational state (if a previous command malfunctioned). Consider implementing Restart() for all the obsStates where abort does not make sense and/or cannot be used).

4) Mostly done with ska-control-model 0.3.4 (REL-1252) – removal of MAINTENANCE to come in ska-control-model 1.0.0 (REL-1292): adminMode - change MAINTENANCE to ENGINEERING to better match the meaning, (and to avoid confusion with the DISH MAINTENANCE mode). This has been agreed long ago but never implemented. Given that this is a breaking change it has been agreed that in the first step 'ENGINEERING' will be added to the enumeration (ska-control-model 0.3.4 REL-1252), and then MAINTENANCE will be removed as the next step (ska-control-model 1.0.0 REL-719).

5) Done and released with ska-tango-base 0.20.1 (REL-1260): Limit the number of commands that can be inserted in the input queue - this is follow up on PI20 work on https://jira.skatelescope.org/browse/SP-3350 . Most use cases devices in the SKA Telescopes result in one command issues at a time, but some of the devices in MCCS a rather large capacity queue - this need to be re-considered. Queue capacity is an arbitrary number and can be re-considered during commissioning and testing,

https://confluence.skatelescope.org/pages/viewpage.action?pageId=105416556