h5xx/attribute.hpp: fix reading of NULL padded strings

The DataType passed to H5::Attribute::read must be consistent with the
actual DataType in the file. In particular, the string padding must be
the same. Instead of constructing a new DataType object, use the one
obtained from H5::Attribute.
attribute::read: fix reading variable-length strings

Variable length datatypes require a different treatment since the HDF5 C
library allocates the memory. See the code in
H5::Attribute::p_read_variable_len() for a reference.
remove locally defined, but unused typedef

GCC 4.8.2 warns about locally defined, but unused typedefs.
support attributes of type std::vector<std::string>

Only fixed-length strings are supported by now.
attribute: fix reading of string arrays

In the buffer filled by H5A_read(), the longest string is not
'\0'-terminated. Just converting the C strings to std::string resulted
in excessively long strings.

The issue was overlooked by the test since the longest string was the
last one (and the buffer was followed by a 0, obviously).
attribute: fix reading of NULL-padded string arrays

The padding of the memory datatype must coincide with the padding of the
file datatype. Simply re-use the file datatype in H5Aread.

Potentially, there could be an issue with SPACE-padded strings (which
should be converted to NULL-padded). However, selecting SPACE padding
upon writing did not change the way h5dump displays the attribute
(although the different padding was shown). Using FORTRAN_S1 as String
type (which has space padding by default) compiles but is still reported
as C_S1 by h5dump and everything is filled up with '\0'. Probably a
genuine Fortran code would be needed to generate such a file.

Second fix: don't explicitly include the trailing '\0' for
NULL-terminated strings. The strings are delimited by '\0', but have
STRSIZE characters at most.