Expose hFILE_backend and hfile_init to allow custom hFILE implementations

[adamnovak]

I have a custom hFILE backend over C++ streams that I have written for vg: https://github.com/vgteam/vg/blob/39ac300bb735abf8350e3d2a7ec0356a0742fd56/src/stream/hfile_cppstream.cpp

It has built just fine up until now, since vg ships htslib as a submodule and I can just include hfile_internal.h from it and get the definitions of hFILE_backend and hfile_init.

But now I want to refactor vg's IO logic into its own project, with a dependency on whatever htslib the environment provides. The htslib install process does not install hfile_internal.h, so I can't get at the definitions I need.

I see now that my work is somewhat redundant with #647, but it seemed like in that thread people thought the right thing to do was to just make the backend system available to client code instead of adding a new callback system over it.

For now I'm going to adopt the workaround from https://github.com/samtools/htslib-plugins and just ship my own version of the header and hope that hFILE_backend never changes. But really the type should be exposed so that custom htslib-version-independent hFILE implementations are possible.

[daviesrob]

Yes, the fact that htslib-plugins needs its own copy of hfile_internal.h suggests that something is missing for plug-in developers. Given that the interface isn't going to change, moving the bits needed into a new htslib/plugin.h file would likely be the best solution.