Fix object copies across drivers

[markcmiller86]

A user reported problems attempting to use DBCp() to copy a whole file between PDB and HDF5 formats.

Object copying is handled via the generic methods DBGetObject() and DBWriteObject(). However, there are a number of subtle differences in the way the two drivers handle metadata when building these generic objects. These differences appear in various ways...

• how tiny, immediate mode array members such as for extents (e.g. "'<d>11,13,15'") are handled
• how time and dtime members are handled
• how datatype member is handled
• DBCp() was not handling its return value correctly

On the HDF5 driver, these generic objects are used to define HDF5 struct-like types. If for some reason, those struct-like types are subtley different than what the HDF5 driver read methods such as DBGetUcdmesh() are expecting, the objects can fail being read.

OTOH, On the PDB driver, if the datatype member is not handled correctly, that can corruped handling of bulk data returned with various objects.

There is another case of tiny arrays that is used in Silo that has to do with the python module. They involve a similar purpose but where the target is a python dict object.

This PR fixes several issues found by adding a test to dir.c test that does a whole file copy of multi_ucd3d.pdb to an HDF5 formatted file.

This PR also adds a DBDriverVersion() method to the Silo public API so that callers can obtain the underlying driver's library version information.