sbus: Add meta data structures and code generator

These metadata structures hold the information about all the
details of a DBus interface. They are typically generated from
the canonical XML form of the DBus interface, although they
may also be hand crafted.

Add some handy functions for looking up methods, props, signals,
in the metadata of an interface. Currently lookups are just done
by looking through an array. If performance becomes an issue (ie:
very large interfaces) it would be really easy to sort things
and use bsearch().

Later commits will include some definitions using this metadata
and related functions.

DBus interfaces are defined here:

http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format

The introspection data format has become the standard way to represent a
DBus interface. For many examples see /usr/share/dbus-1/interfaces/ on a
typical linux machine.

A word about annotations. These are extra flags or values that can be
assigned to anything. So far, the codegen supports this annotation:

org.freedesktop.DBus.GLib.CSymbol
 - An annotation specified in the specification that tells us what C symbol
   to generate for a given interface or method. By default the codegen will
   build up a symbol name from the DBus name.

It is possible to confuse the code generator into producing invalid
C code (with strange method names, for example), but the C compiler
catches such silliness right away.

Add tests testing basic features of the codegen and poking through
the metadata it creates. Also test the metadata lookup functions.

Generated code is checked in for easy discovery.

An example of the XML interface definitions can be found at:

  src/tests/sbus_codegen_tests.xml

And an example of the generated header can be found here:

  src/tests/sbus_codegen_tests_generated.h
sbus: Add sbus_vtable and update codegen to support it

Each interface is a vtable structure derived from
sbus_vtable, in the sense that it has an sbus_vtable
struct as its first argument. This lets us upcast the
interface vtable structure to an sbus_vtable and dispatch
to it dynamically and cleanly.

The interface metadata contains information about which
vtable offset in the interface metadata should be dispatched
to for a given function. This is a common scheme, not only
among dbus implementations, but also compiled languages.

Currently all the vtable functions are of type
sbus_msg_handler_fn. These are the handlers we are familiar
with and perform raw processing of the message. Later commits
will introduce type safe handlers that levelage compile checking
and automatic argument packing/unpacking.

Although this may seem contrived now, the remainder of the
dbus infrastructure work will build on this, including
ofd.Properties, ofd.ObjectManager, ofd.Introspect, compiler
checked type safe unpacking/packing, etc.

The codegen now generates vtable structures for each interface
along-side the metadata, and fills in vtable offsets
appropriately.

It is obviously still possible to hand-craft such vtables and
metadata if needed for a special case.

Once again examples output can be found at:

  src/tests/sbus_codegen_tests_generated.h
nss: Stop using one DBus interface with totally different methods

This is an incorrect use of DBus, where we use a single interface
name with completely different sets of methods.

Easily fixed.

Once the vtable stuff is in use then this would be automatically
detected and fail to build.
sbus: Rework sbus to use interface metadata and vtables

Previous commits added support for interface metadata and
handler vtables. This commit ports sbus_dbus_connection to
use them.

Port the internal uses of dbus to use the new scheme in a
very minimal way. Further cleanup is possible here.

This commit provides basic definitions of the internal
dbus interfaces. The interfaces aren't fully defined, as the
handlers will continue to unpack manually, and often overload
DBus methods with different arguments (which is rather
unorthodox, but not the end of the world).
sbus: Generate constants from interface definitions

This is not strictly necessary, but avoids duplicating data
in mulitple places, and makes the interface definitions
benefit dbus callers (a little).

After applying this commit you may need to 'make clean' as
the codegen has changed.
sbus: Use constants to make dbus calls

This allows us to remove duplicated information, and have the
compiler check that when an method name is changed or removed
the callers are updated.
sbus: Add sbus_request context

struct sbus_request represents a request from a dbus client
being handled by a dbus server implementation. The struct
contains the message, connection and method which is being
invoked.

In the future it will contain caller information as well.

sbus_request is a talloc memory context, and is a good place to
attach any allocations and memory specific to the request.

Each handler accepts an sbus_request. If a handler returns
EOK, it is assumed that the handler will finish the request.
Any of the sbus_request_*finish() methods can be used to
complete the request and send back a reply.

This patch migrates the monitor and data provider dbus code
to use sbus_request, but does not try to rework the talloc
context's to use it.
sbus: Refactor how we export DBus interfaces

Most importantly, stop using per connection private data. This doesn't
scale when you have more than one thing exporting or exported on a
connection.

Remove struct sbus_interface and expand sbus_conn_add_interface()
function. Remove various struct sbus_interface args to connection
initialization functions and make callers use sbus_conn_add_interface()
directly. The old method was optimized for exporting one interface
on a connection. We'll have connections that export zero, one or more
interfaces

To export an interface on a DBus server, call sbus_conn_add_interface()
from within the sbus_server_conn_init_fn. To export an interface on
a DBus client, call sbus_conn_add_interface() after sbus_new_connection()
returns.

However, we now have type safe interface exporting in the various
high level sss_process_init() sss_monitor_init() and so on.

Introspection support was not in use, and is now gone until we
implement it using the metadata (future patch).
sbus: Make sbus_new_server() work for non-priveleged processes

I'd like to use this during testing. We should check that the
socket ownership is the same as the process, rather than limiting
it to root.
sbus_codegen_tests: Add some testing of dispatch and handler code

This starts a DBus server with some handlers, and runs some method
calls against it.