First Stage of sdbusplus mocks

[Patrick Venture <venture@google.com>]

Everyone;

Mocks:
https://gerrit.openbmc-project.xyz/#/c/10046

I've only implemented mocks for sdbusplus::bus::bus and
sdbusplus::message::message (append() & read()) at this point.  Next
I'll be tackling other parts of sdbusplus.

Basically you can now verify the calls into sdbusplus, and the
parameters passed to the messages.  Which is pretty valuable.
However, nearly all of openbmc was written without unit-testing in
mind, so few things have easy injection points.  This'll have to
change over time as unit-tests become prolific inside openbmc.   In a
previous email I talked about using interfaces in libraries for
everything so that you could get mocks for free :D  That's the way we
need to go, and so I'm going to do some basic library implementations
with mocks and see how people like them (or dislike them).  The idea
being, anything you're calling should be mocked so you can easily test
the code. :)  Easily being key.

Examples of usage:
https://gerrit.openbmc-project.xyz/#/c/10048

Please take a look and provide some feedback.  The sdbuplus mocks
aren't compiling in the CI, but did compile locally (as obvious by my
usage of them in a unit-test and a live image).  So I would appreciate
some insight into what might be going on there.

Next on my plate for attack:
sdbusplus::server::interface::interface
sdbusplus::server::manager::manager
sdbusplus::server::object::details...
sdbusplus::server::transaction...

and seeing what openbmc daemon is easiest to rip apart into testable
units, to provide more examples.  phosphor-pid-control doesn't compile
with upstream, otherwise I'd start there as I'm familiar with the
daemon and it was written in lots of pieces for testing.

Regards,
Patrick