deb: new debian/configure and debian/control*

This one's written in python instead of bash, and has a cleaner internal
structure.

This handles the flavored debs of the unified-build-candidate branch.

The new command-line interface is nearly backwards compatible with the
old debian/configure.  The only difference is that "-a" no longer means
"try to configure for the running realtime kernel, and if that fail fall
back to any installed realtime kernel", it now means the same as "-r":
"configure for the running realtime kernel".  I think that's the only way
"-a" was ever used.

The new debian packaging produces linuxcnc.deb, linuxcnc-dev.deb,
and linuxcnc-doc-*.deb, just like before, and in addition produces
linuxcnc-$FLAVOR.deb for each flavor enabled by debian/configure.
The available flavors are:

    posix (what we used to call sim)

    rtai-kernel (what we used to call rt)

    rt-preempt

    xenomai (FIXME: not fully implemented yet)

    xenomai-kernel (FIXME: not fully implemented yet)

linuxcnc.deb depends on at least one of the flavor debs, and suggests
all of them (to make them easy to find in the package manager, mostly).
deb/conf: accept -a to mean -r

"debian/configure -r" is supposed to mean "configure for the running
realtime kernel", and "debian/configure -a" is supposed to mean "configure
for any realtime headers you can find on the system".

The buildbot ill-advisedly runs 'debian/configure -a', even though it
knows it's going to run runtests later (so the kernel it builds for must
be the one that's running).  So really -r would be more correct.

In practice it's fine because all the buildslave VMs only have one
realtime kernel installed, so there's no difference between -a and -r
on those hosts.

If someone cares strongly about the difference between the old "-a"
and the new "-a" we can reinstate it.

As an aside, it probably makes sense to add a "debian/configure --all"
option that examines the apt database and makes the dsc build-depend on
all *available* realtime kernel headers.
deb/control: get rid of ancient Provides in control

I think it's time to stop worrying about users upgrading from emc2.deb
packages.
deb/control: relax the Conflicts

The flavor packages should conflict with pre-ubc packages, but there's
no convenient way to specify that currently.

When we merge ubc into master we'll tag that point as 2.6.0-pre1,
and make the post-ubc debs conflict with linuxcnc < 2.6.0-pre1.
deb/rules: dont use cpio when cp will do

Debian Wheezy doesn't come with cpio by default, this commit lets us
not add a build-dependency on it.
install rsyslogd.conf file
give dlopen the path to the ulapi library

Normally dlopen() searches LD_LIBRARY_PATH and /lib and /usr/lib.  In rip
builds we set LD_LIBRARY_PATH and we could do the same in installed
scripts, but it seems simpler to teach ulapi where the files live.
put ulapi-$flavor.so straight into rtlib/, not lib, so the dlopen can look in EMC2_RTLIB_DIR