clarify handling of deprecated libraries

[Jeff Johnson]

Currently deprecated libraries are included in LSB versions where they are
deprecated. This is certainly correct for the runtime environment -
specification, checkers, etc. Whether it's the correct approach for the stub
libraries in the development environment is less clear.

The question arises particularly in the case of libpng12, which needs to be
deprecated to accomodate the ABI-incompatible (at least partly) libpng15.
Since the changes are visible in the png.h header as well, LSB header version
protection means there will not be a way to build targeting LSB 5.0 and
libpng12 using the png.h header, because the version ifdefs will pick the
changes that match the libpng15 uplift. Thus it's possible the stub for this
library should be omitted from the stub libraries. As a contrast,
libgtk-x11-2.0 and libgdk-x11-2.0 will be deprecated in favor of libgtk-3, but
here the intent is to continue to be able to buiild for the old version, done
through a disjoint set of headers.

This is filed to track the question of whether there are cases where the stub
should actually be omitted, and if so how to make it work.

As an alternative, it's probably possible to force the "old" png.h header into
a distinct path (/opt/lsb/include/libpng12/png.h) and tell people they have to
use #include <libpng12/png.h> if they want to access the old way, but it's not
clear whether this is going to be "industry standard".