Further removal of HDF4 code from HDF5 code (2nd attempt)

[edhartnett]

In this PR I continue the removal of HDF4 code to it's own dispatch layer. This is all leading eventually to user-defined formats (#177), and more directly to #856, the separation of the enhanced model internal code from the HDF5 dispatch layer.

Removal of HDF4-specific Fields from _INFO_T Structs

After #856 the INFO_T structs will not contain any format-specific fields. We mostly have been discussing the (many) HDF5 fields this will impact.

But the file and variable info structs also contain some HDF4-specific fields. In this PR these have been replaced with void pointers. The pointers are used by the HDF4 dispatch layer to manage these fields. All knowledge of these fields now resides within the HDF4 dispatch code.

These same void pointers will be used to achieve the same results with the HDF5 specific fields.

HDF4 Tests

In this PR I move the HDF4 tests to new directory hdf4_test. This is straightforward - there are no dependencies on other non-HDF4 tests.

This will be necessary to enable builds with HDF4, but without HDF5. It also simplifies the already-complex build in nc_test4, and is in accordance with the dispatch layer conventions outlined in the documentation.

I also removed a shell test which only ran a C test; now the C test runs without the shell. Two other shells were combined to eliminate a dependency on tst_interops2.

Reusable Dispatch Functions

There are many functions in the HDF4 dispatch table which simple return error codes (for example, all the functions that write to file return NC_EPERM, since the HDF4 dispatch layer is read-only). I have given these functions general names and moved them to the dispatch directory. (For example RO_def_var() for an nc_def_var() function for a read-only dispatch layer.)

I have used some of these functions in the libsrc4 and libsrcp directory, removing some code duplication. They can also be used in at least some cases in the dap directories, but I have not ventured that.

Documentation

I have added documentation to docs/internal.dox.

• The reusable error-returning functions are explained and enumerated.
• The HDF4 layer is also presented as an example of a simple dispatch layer. All HDF4 impacts on the code base are documented, so other programmers can easily see all changes that are needed to implement a dispatch layer.

I am happy to discuss and implement any suggestions for documentation improvement or development. I will present further documentation for proposed changes for #856 this week, but this PR deals with HDF4 only.

Valgrind Removal

The obsolete valgrind stuff has been removed from the build.

Part of #856.
Fixes #873
Fixes #870
Fixes #871
Fixes #869
Fixes #849

[edhartnett]

I will take this down until Dennis' recent PR is merged, then I will re-integrate these changes and put up another PR.

[DennisHeimbigner]

A note on naming. We have, as a rule, used the name prefix "nc" or "NC"
as a defacto name space for any global object (e.g. variables and functions)
defined in the netcdf-c library. So, you have a number of functions
such as RO_XXX and NOTNC4_XXX that violate this project style.
Can you go thru your code and fix these please?

[edhartnett]

Sure.

How about NC_RO_def_var(), NC_NOTNC4_def_compound(), etc. In other words, add "NC_" to the front of all the names I am using.

Or something else? I am open to suggestions.