Begin migration to BuxtonControl

Currently direct and wire-based clients share the same API, potentially
enabling non-direct clients to use non-client code.

We will begin a migration to BuxtonControl, which can only be used by
the CLI tool with --direct mode, and by bt-daemon. Direct users are
to become responsible for the state and internal tracking of buxton,
such as maintaining loaded backends and layers, as opposed to retaining
these as global variables within libbuxton.

By removing this functionality, we can drop many redundant checks,
and trim the public section of the library further. Currently the
BuxtonConfig struct is a placeholder, which will be utilised when
backend implementation specifics are migrated from libbuxton to
backend.{c,h}

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Move direct management functions into backend.{c,h}

Instead of exposing private internal functionality, only the CLI
and daemon can now make use of direct management of Buxton. Some
redundancy was reduced by introducing methods of checkin the
clients "direct" status.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
test: Migrate tests to new direct API's

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
shared: Store the BuxtonControl for direct access

In instances where direct access is used (CLI, daemon) the library
needs to gain access to the configuration used within BuxtonControl
in order to do layer operations, etc.

Instead of storing a BuxtonClient we'll store the BuxtonControl and
use that for direct access validation.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
shared: Add buxton_get_config

The library will at times need access to the configuration of Buxton,
namely the layers and backends. In order to facilitate this, a direct
client is associated with a BuxtonConfig, which globally stores these
important parts of Buxton's state.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
shared: Replace libbuxton's layer implementation

backend part of buxton is now responsible (entirely) for layer management,
removing this logic from the public API.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
shared: Move backend-specific code into this part of the tree

libbuxton no longer handles or exposes backend specific loading
or configuration, with these being configured now by a direct
mode BuxtonControl's configuration.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
shared: Add buxton_direct_close

Direct mode clients will now need to cleanup using this method instead
of relying on the library exit handler, which is now gone.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
shared: Add direct methods for internal API
api: Move client and daemon direct over to the internal api

Also make the smack and the check tests use the internal API as
needed.
libbuxton: Remove direct open from public API

Signed-off-by: William Douglas <william.douglas@intel.com>
api: Remove direct references from public API

Also remove set-label for now since we don't support non direct at the
moment.

Signed-off-by: William Douglas <william.douglas@intel.com>
core: Handle responses per message type

Previously buxton used a test on get_value's output to detect if it
needed to respond to clients with one parameter or two because there
was only two daemon functions. Now that there are more functions make
responses based on the type of message buxton received.
core: Add some extra debug logging

Signed-off-by: William Douglas <william.douglas@intel.com>