spec cleanup: versioning

[Jeff Johnson]

Recording some work that should be done: the way versioning happens in the
specification builds. Roughly speaking, there are two interesting numbers:
spec version, and target spec version. These two match only rarely - when an
official release is being made. During development, the spec version by
convention starts lower than the target version, such as 4.80, 4.81, 4,82 etc.
edging up to 5.0, which is the target.

In the spec builds, the spec version is added by editing foo.spec.sed into
foo.spec by applying a rule in Makefile.common which exracts the version from a
file. To make a date-stamped version, this rule is applied:

dateversion:
        echo `cat $(SPECSRC)/LSB/version.$(ARCH)`-`date +"%Y%m%d"`
>buildversion;\
        sed -e "s#LSBVERSION#`cat $(SPECSRC)/LSB/version.$(ARCH)`-`date
+"%Y%m%d"`#" <$(DOC).sgml.sed -e "s#SPECSRC#$(SPECSRC)#">$(DOC).sgml

incidentally, ARCH is not derived, it is hardcoded in the individual book
makefiles, so LSB-Core-IA32 says ARCH=IA32, LSB-Imaging/makefile says
ARCH=generic.

The spec version might also be used in the introductiory sections, which might
say something like "This is version 4.80 of the FOO specification. When
approved it will be version 5.0".

Meanwhile, the target version is used all over lsbspec, as an argument to
generator scripts which use that version when doing queries on the database.

At the moment, there are a variety of files containing versions spread across
the lsbspec directory, at last count 46 of them. The spec build directories
only know about finding versionfiles in LSB. This has both version.arch and
target_version.arch files (where arch is one of the eight possible values).
The other module and submodule directories have various version files which may
have been added without too much consideration, and makefiles below will have
paths with a lot of dots in them.

This bug requests a couple of levels of review:
-- decide whether versions are per-lsbspec or per-module - that is, does one
common set of versionfiles suffice or do they belong in each mod/submod dir
-- consistently apply the above rule
-- consider if we can have way to distinguish production and non-production
builds, so we can reliably in each book tag it as a draft or not.