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 matadata of an interface. Currently metadata is 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 creats. Also test the metadata lookup functions

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

  $(srcdir)/src/tests/sbus_codegen-defs.xml

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

  $(builddir)/src/tests/sbus_codegen-defs.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 them in 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:

  $(builddir)/src/tests/sbus_codegen-defs.h

You'll likely need to 'make clean' after applying this patch
as this modifies the codegen.
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.