BUFR table management support

*Christophe Beauregard wrote:
There's probably some need to add API support for dealing with BUFR table
management beyond the simple loading of the one current CMC-format table which
is currently supported.

The current state of the API is:
1. there is rudimentary support for building on-the-fly tables
(bufr_create_tables, bufr_new_EntryTableD, bufr_new_EntryTableB, and the low-
sources/formats by applications (i.e. read from RDBMS)
2. there is support for reading CMC-formatted tables, and loading CMC-format
tables pointed to by the BUFR_TABLES environment variable
3. there is support for dealing with table embedded in BUFR messages
4. there is a way to discover table version information from the BUFR message
and act on that information (find and load tables) before decoding

Table management should assume that multiple versions of tables might exist, for
different table categories, and that BUFR messages will tell us what versions we
should be using. Table management could also have some concept of overriding
this information where it might be erroneous (*cough* vertical profiles
*cough*).

We've tentatively concluded that the most logical approach to table management
for EC and libecbufr is to divide the problem into two separate issues:

1. for libecbufr, we include some functionality to handle the forthcoming WMO
machine readable formats. If other formats are "common" (ECMWF?), it might also
be desirable to have functions to handle them, as with the existing
bufr_load_*_table*() functions to handle CMC format tables.

2. for EC, we may wish to move the whole problem of table management to a common
library tied to the table maintenance and distribution process. This may be
necessary if the chosen management technique have complex and/or non-portable
dependency requirements (i.e. SQLite, or explicit ties to EC infrastructure like
the DMS). Alternatively, EC applications may have to roll their own table
management.

*Yves Pelletier wrote:
The table management scheme will also have to take into account the status of
the Table B or D descriptors. Status can be one of three things: validation,
pre-operational, and operational.

The Master Table version number will also become crucially important. Current
version 13 is backward-compatible with all previous versions. This will no
longer be the case with version 14. We will need efficient version tracking -
either on the table as a whole, or on a per-descriptor basis.

Mark McCrady, of my team, is starting to look at the following ideas, which
could be experimented with without too much trouble:

1. For both Tables B and D

Separate existing table B and D into four tables:
Operational, Pre-Operational, Validation and Local.

Table D and Table B version numbers will be synchronized and identical.

The operational table would have version number 13; pre-op would have version
number 14. When the operational table is upgraded to version 14 by decision of
CBS, the approved pre-op descriptors will be migrated to the operational table
and the pre-op table would be upgraded to version 15.

The validation table would have a constant version number of 255.

The local table version number will be incremented as required at the discretion
of the Table maintainers and in coordination with the user base.

2. For Table D
A comment line will be inserted above sequences to document, at least with a
one-liner, what it is for.