Update .gitignore for 'make check' built files
util: Fix const cast failures when building with -Werror

When building with -Werror 'make check' fails with many
errors like:

../src/tests/cmocka/test_authtok.c: In function ‘test_sss_authtok_password’:
../src/tests/cmocka/test_authtok.c:98:48: error: cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Werror=cast-qual]

Make sss_authtok_set() @data argument const, and fix its documentation
util: A safe printf for user provided format strings

Since the default printf(3) implementation cannot safely be
used on user (or admin) provided input, this is a safe implementation.

This will be used in later patches by the full_name_format option
The implementation came from realmd, but only has libc dependencies.

The number of fields is pre-defined, and safe printf fails if
an invalid field is accessed.

Only string fields are supported, and only flags relevant to string
fields are supported. Width and precision work as expected, but
precision cannot read from a field.

Tests are included, and ported to the check based testing that
sssd uses.
NSS: Don't use printf(3) on user provided strings.

This also fixes several corner cases and crashers.

It's not prudent to pass user input to (even admin) input as a
format string to printf, and various distros now check for this.
This can cause accessing memory incorrectly, and various also
various libc abort()'s.

In addition various assumptions were made about full_name_format
that aren't necessarily the case if the user uses a more complex
format.

Use safe-printf.c implementation for formatting full_name_format.

Adapt the NSS resolver so it doesn't barf on formatted strings that
are shorter than expected given a full_name_format.

Tests added and updated appropriately.
configure: Enable usual SSSD_WARNINGS automatically

Instead of limiting these to Fedora based sssd developers
via the bashrc_sssd script, enable them automatically in
configure if supported by the compiler.
configure: Add strict compilation mode with --enable-strict
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.