Alembic is not a single file format, it can be stored in two different
ways: Ogawa and HDF5. Ogawa replaced HDF5 and is smaller and much faster
(4-25x) to read ([source](http://exocortex.com/blog/alembic_is_about_to_get_really_fast)).
As long as Blender has had Alembic support, it has never supported the
HDF5 format in any release. There is a build option `WITH_ALEMBIC_HDF5`
that can be used to enable HDF5 support in your own build. This commit
removes this build option and the code that it manages.
In the years that I have been maintainer of Blender's Alembic code, I
only remember getting a request to support HDF5 once, and that was to
support very old software that has likely since then been updated to
support Ogawa. Ubuntu and Fedora also seem to bundle Blender without
HDF5 support.
This decision was discussed on
[DevTalk](https://devtalk.blender.org/t/alembic-hdf5-support-completely-remove)
where someone also mentioned that there is a tool available that can
convert HDF5 files to the Ogawa format.
In rB7c5a44c71f13 I changed the way transform matrices are loaded from
Alembic. Instead of having the Alembic importer convert matrices from
local (in the Alembic file) to World (to pass to the constraint handling
the animation of transforms), I set the constraint space to
`CONSTRAINT_SPACE_LOCAL`.
This worked thanks to rB7728bfd4c45c. However, that commit was reverted,
which meant that for parentless objects `CONSTRAINT_SPACE_LOCAL` no
longer means "local space".
The situation is resolved by setting the constraint to world space
again, and computing the world matrix in the Alembic importer.
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
