Possibly wrong metadata type for log names when importing RMS well from HDF5

[ErichSuter]

#1194 allows well log metadata values (values in key/value pairs in a dict named wlogrecords) to be represented as Iterable to fix the following: in the two tests (tests/test_well/test_well.py::test_hdf_io_single() and tests/test_well/test_well.py::test_import_as_rms_export_as_hdf_many()) log names can be both lists ands dicts when received from json.loads() that is used to deserialize the well from an HDF5 file, while in xtgeo/well/_well_io.py::import_wlogs() an exception is raised when they are lists.

The two tests have been commented out for a period of time. They have probably worked earlier, then other parts of the code have changed while they were commented out. When re-introducing the tests, problems have surfaced.

HDF5 file handling is relatively new in xtgeo. The mix of dicts and lists from the json conversion may be wrong, or it may be wrong to accept only dicts. If it turns out that the json.loads() should be upgraded, this could be achieved by customizing a JSON encoder and/or decoder to control the types at the deeper levels of the hierarchy. Note that the object_pairs_hook is needed to handle repeated names in the loaded JSON (at the top level only?), otherwise one may lose data in the conversion.

Note that the consistency of the data is checked in xtgeo/xyz/_xyz_data.py::_ensure_consistency_attr_records(). This method is assumedly used to check also the consistency of geometric metadata. Hence, it defines some rules about metadata consistency in xtgeo.

Even though the two tests pass when relaxing the requirement for raising an exception, it may indicate an underlying inconsistency problem related to the type of the metadata records (dict, list, tuple).

This problem seems not to cause more severe problems for the time being.