(Instead of completely dropping it!)

(Of course, this doesn't really matter right now because the
non-static functions in mul/mul_of.h isn't exported into libmul.a
right now.)

automake 1.15 (current Ubuntu default) will fail due to the
long-lived subdir-objects / _SOURCES bug.

It's nontrivial to work around this in the MUL codebase, since
the apps build using a C main stub file in a different subdir.

Hence automake-1.11, which is happily still available for newer
Ubuntus.

Ok, nobody uses these priv_*_alloc callbacks, I guess.  Well, I do!

Nothing uses this other than the nbapi stuff, and me.  I suppose this
could potentially break that, but I doubt it.  If anything, that code
would be buggy.

MUL's application skeleton that they like us to use (and that saves
us work) sucks down all the command-line opts via getopt and doesn't
expose it to the application.  It also parses options before it
initializes the application "modules", so we can't supply a new app
callback to handle the opts.

Thus, we add what is basically a secondary initcall-like thing,
except this one is a struct of callbacks (including the per-app
getopt parsing function) and data (like the opts and longopts).  So
the macros define a section of per-module getopt parsing info
struct pointers, and before calling getopt, the skeleton main
expands its opts, longopts, and usage with info from these per-app
getopt helper info structs.

So it really is like a (very) poor man's argp.

Every time you think you've reached a new low with autotools, you're
wrong.  This is my way to get around the standard installable
config.h problem.

Basically, MUL wants you to include headers that require config.h,
but of course things that use MUL have config.h of their own.  So --
we take the hacky approach and remove the things that will obviously
conflict and stick them in mul_config_internal.h .  I'm sure my way
of doing this will be missed if config.status common/mul_config.h is
ever run to regen mul_config.h, but I can't solve that one right now.

I improved the MUL build and install (and application build!)
in several ways:

  * Use pkg-config to detect glib-2.0 .  Sadly, the Makefile.ams
    are not really amenable to easy modification to support the
    resulting flags, so that's why I did what I did.  The whole
    glib include/libs thing should change...

  * Support external object tree builds, not just builds in the
    source tree.  Lots of $(top_srcdir) action here... and included
    in that morass are updates of bad things, like linking to
    <path>/.libs/libfoo.a -- ugh -- instead of <path>/libfoo.la --
    because that's how this build was set up, and it kind of wants
    to be that way for some symbol stuff I didn't care to dig into.
    I think it has to do with the way apps are built, and some
    symbol deps that the shared objs have, but like I say, I don't
    care right now.

  * Support applications built from the installed version of MUL.
    This means we had to install all the headers, and it means that
    we moved from using config.h to mul_config.h , to minimize
    future chances of config.h collisions, heh.  We also install
    the application source skeleton (that has the application
    main()) in $(prefix)/share/openmul/app_mul_main.c or whatever.
    Works like a charm; no more funky app build foo.

So don't try to install man pages that haven't been generated.

Merge concave to master