appbat not buildable with VI-SDK when target vers is different than SDK default

[Jeff Johnson]

Filing this against appbat, not sure where to put the blame, but things are
definitely broken.

Appbat does a lot of careful setting of PKG_CONFIG_{PATH,LIBDIR} as well as
patching to convince pkg-config and libtool to use /opt/lsb/lib{,64}. This
works OK, *until* the sdk moves on and we try to build an "old" appbat with a
new sdk.

Take the current struggle to build the 4.0 appbat with the current SDK, which
defaults to 4.1 (or 5.0 if it's from snapshots):

First we build libbat, which has already had some additions to move things to
lib{,64}-4.0. OK, all fine and good, except that the .pc files and foo-config
scripts we include in libbat all point to lib{,64}, with no version suffix.
Using the 4.1-targeted "independent" SDK, lib -> lib-4.1, and libbat ain't
there, it's in lib-4.0.

OK, so we use some sed action and fix all the .pc files and config scripts to
look in 4.0, simple addition, now libbat should behave as expected.

But, all the rest of the app builds are still looking for things in plain
"lib", and guess what, libbat ain't there and things blow up gloriously.

So I had to go back and alter almost all the xml files, plus a patch in
celestia that forces libtool to look in the right place so everyone looks in
lib-4.0.

LSBCC_LSBVERSION makes lsbcc do "the right thing", but it doesn't impact these
other tools.

Same thing will happen when we try to do updates on 4.1 appbat if the SDK has
moved to 5.0.

So, we either need to do as I did with the 4.0 tree and target the appbat build
for the LSB version it's meant for, or come up with a means for lsbcc? (what
about the rest of the toolchain, do moc and friends do the right thing?) to
handle the situation.

Seems very odd to me to have to do such extensive changes to something we've
released and done updates on before, because the build environment has changed
out from under it.