Clean up use of 'extern "C"' in header files

[DimitriPapadopoulos]

Private header files are only seen by the C compiler that builds the library. They don't need extern "C".

Public header files can be seen by a C++ compiler. They do need the extern "C". And it's best done individually in each public header file. On the other hand, header files that just use directives of the preprocessor need not extern "C".

[FrancescAlted]

I'll say upfront that I am not a C++ guy. As far as I remember, this kind of protection was proposed by somebody many years ago to go into C-Blosc(1) code, and we adopted that convention (admittedly without any specific rule, because other headers are not protected this way).

Frankly, I don't know what to do here, but I'd appreciate if somebody else with C++ experience can chime in and reassure me by approving this PR.

[DimitriPapadopoulos]

I can also add these to all header files. However, that's useless for private files, since these files are supposed to be compiled only by the C compiler that builds c-blosc2.

I am under the impression that the API of c-blosc2 is not well-delimited, and that you may have external code, or at least plugins, include private header files (#500 (comment)). In that case, it might make sent to protect private header files too, in case you include them from C++ code.

[FrancescAlted]

Ok. I have been talking with a mate that is more familiar with C++, and what you are suggesting makes sense. It might be that C++ projects (e.g. dynamic plugins) may use private header files in C-Blosc2, but this can be addressed later (if needed).

Thanks!