Manually setting properties of empty property lists.

[1uc]

In #783 a user reported that:

auto props = HighFive::GroupCreateProps::Default();
H5Pset_attr_phase_change(props.getId(), 0, 0); // force dense storage

fails with

HDF5-DIAG: Error detected in HDF5 (1.10.7) thread 1:
#000: ../../../src/H5Pocpl.c line 237 in H5Pset_attr_phase_change(): can't find object for ID
major: Object atom
minor: Unable to find atom information (already closed?)
https://github.com/BlueBrain/HighFive/issues/1: ../../../src/H5Pint.c line 3822 in H5P_object_verify(): property list is not a member of the class
major: Property lists
minor: Unable to register new atom
https://github.com/BlueBrain/HighFive/pull/2: ../../../src/H5Pint.c line 3772 in H5P_isa_class(): not a property list
major: Invalid arguments to routine
minor: Inappropriate type

which would make sense, because we internally store an invalid HID until something gets set. This allows us to pass H5P_DEFAULT if the property list is empty.

[1uc]

The invalid "HID" is H5P_DEFAULT (which happens to be 0). This leads to strange semantics:

auto pl1 = DataTransferProps::Default();
auto pl2 = pl1;
// As usual shallow copying semantics:
assert(pl1.getId() == pl2.getId());

// Then one adds something and the link is broken:
pl2.add(...);
assert(pl1.getId() == H5P_DEFAULT);

// but once it's not a "special" value, regular shallow copy semantic
// return:
auto pl3 = pl2;
pl3.add(...);
assert(pl3.getId() == pl2.getId()); 

Unit-tests assert this behaviour and it's observable by users. Hence, we can't easily change this until v3.