ska-tango-base: Long Running Commands - improve status reporting, implementation of Abort(), add LRC to the Base Class client.

Below are three suggested improvements for ska-tango-base which it was felt need
doing, but we realised too late to make it for the ska-tango-base release 1.0.0.
The first of these is relatively independent of the other two.  The second is an
enabler for the third.

1. Rename the SKABaseDevice command AbortCommands() to Abort() and make it an LRC

    During the formalisation of the LRC component manager interface (SP-4069) it
    was difficult to determine how the SKABaseDevice AbortCommands() command was
    supposed to relate to the SKASubarray Abort() command and how
    AbortCommands() should interact with the ObsState machine.

    To avoid having to answer these questions it was suggested that we rename
    AbortCommands() to Abort() so that SKASubarry overrides the Abort() command.
    This avoids issues of what should happen if both abort commands are run at
    the same time and the SKASubarray Abort() command is well defined in the
    ObsState machine.

    The SKASubarray Abort() command is an LRC so the SKABaseDevice Abort()
    command should also be an LRC to match. (AbortCommands() is a
    "fire-and-forget" command).

2. Add a function to invoke an LRC for a client

    The LRC abstraction introduces a client/server interface built on top of
    Tango attributes and commands.  The server side of this interface is
    provided by ska-tango-base and is exposed via a python API for
    servers to add their LRCs.  However, the client side of this interface is
    exposed directly as Tango attributes which clients are expected to subscribe
    to CHANGE events for directly.

    By having clients directly handling their side of the LRC abstraction it
    makes it very difficult for ska-tango-base to change the client/server
    interface.

    By adding a function for clients to use ska-tango-base takes control of both
    sides of the interface, allowing us to make changes.  Also, implementing the
    client side of the interface correctly is non-trivial, so it would be useful
    to have this done in one place rather than having each team have to work it
    out independently.

3. Rework LRC attributes

    During the formalisation of the LRC component manager interface (SP-4069) it
    was found that the names of the LRC attributes do not quite match their
    implementation. Also, it is felt that the current implementation does not
    best serve the needs of developers and operators as each LRC attribute is
    trying to provide information to both operators trying to diagnose issues
    with the system and to clients trying to invoke LRCs.

    The proposed rework is to split the LRC attributes into those intended for
    human consumption and those meant to facilitate LRC invocations.  By
    separating these use cases each LRC attribute can have a more clear
    definition.

    Changing the LRC attributes is a change to the client/server LRC
    interface. This requires the function to invoke LRCs outlined above to hide
    the change from users.  If we made these changes, this function would have
    to work with the current LRC client/server interface and also the new
    client/server interface.

All three of these changes require breaking changes involving the client/server
interface of LRCs.  To avoid requiring teams to having wait for their
dependencies to update first, we should release a non-breaking version of these
changes which introduces the new attributes/command and deprecates the old attributes/command. Later (as a separate feature), we can release a breaking version
which removes the deprecated attributes and command.