ska-tango-base Tango Devices correctly use input queue

When this change is implemented users will be able to issue a sequence of commands instead of forcing users to wait for each command to complete before issuing the next command. The goal is to provide a more robust control system, based on loosely coupled components.

We do not expect users to routinely issue a sequence of commands one after the other, but to be able to handle when that happens (the expectation is that queuing of commands will occur more often when commands are generated manually. 

TANGO devices in ska-tango-base check "is command allowed in the current state/mode" after a command is removed from the input queue (and NOT before a command is inserted in the input queue).

Examples, documentation and all other supporting material is updated.

Support for the  early adopters who upgraded within the same PI provided. 

• ska-tango-base executor has been modified to queue commands:
  • performing is_allowed check for every dequeue before executing a task
  • multiple commands/ sequence of commands can be issued at a time (no need to wait for currently executing command to complete before issuing the next)
• The number of workers available to the executor is set to 1 by default:
  • this means queued commands run sequentially (this is configurable)
• This was to be released in REL-724. But that initial release ticket has been discarded because REL-911 captured the feature in its release
• An example usage is implemented MultiDevice using two new commands (invert and transpose) and illustrated in tests
• A section has been added to the docs under LRCs to explain the input queue and show how to apply this change
• Details demonstrated at TANGO CoP

Identified work:
In our base device we report only the first 64 commands in the queue but we're able to add an infinite number of commands to our executor since the python ThreadPoolExecutor implements a SimpleQueue. The immediate consequence is a device server consuming lots of memory because it will have more items in the queue than the threads are able to work off. The ideal solution will be to reject further commands above a set maximum queue size (or use our own queue with a defined maximum size: probably good to avoid this, see this thread)