Fixes for memory allocation and freeing

[MarkRivers]

This PR replaces calls to malloc() and free() with H5allocate_memory() and H5free_memory(). This is the correct mechanism according to HDF5 Group.

It also simplifies blosc_plugin.c, removes blosc_plugin.h, and does some other minor improvements.

[tacaswell]

The linux travis failures look like real build failures:

/home/travis/build/Blosc/hdf5-blosc/src/blosc_filter.c:209:45: error: ‘false’ undeclared (first use in this function)
     outbuf = H5allocate_memory(outbuf_size, false);

[MarkRivers]

The builds were failing because "false" was not defined. It built OK on my local system, but not on travis. I changed "false" to 0, and then the first 2 Travis jobs completed OK. The next 2 jobs still fail, but simply because apt-get is not defined:

0.04s$ sudo apt-get install libhdf5-serial-dev
sudo: apt-get: command not found
The command "sudo apt-get install libhdf5-serial-dev" failed and exited with 1 during .
Your build has been stopped.

I don't know what those 2 jobs are supposed to do.

[tacaswell]

This seems reasonable and correct to me, however I have not done c++ regularly in a while.

It looks like the mac and windows CI has never passed.

[tacaswell]

Just verifying that when we get here outbuf will always be NULL so free was a no-op?

[MarkRivers]

Yes, it appears not to be needed.

[MarkRivers]

Please don't merge this yet. The HDF5 Group developers are in internal discussions about how filter plugins should be doing memory allocation. I was told that using H5allocate_memory() and H5free_memory() is the correct way to do it, but now it seems that they are not sure about this.

[tacaswell]

Changing me review to request-changes due to @MarkRivers 's comment about HDF5 group's internal discussions.

[FrancescAlted]

Ping. I plan to do a release soon, and I am curious if this is still valid or not.