Allow making KSORT functions static

[jmarshall]

Consider the following program:

#include "htslib/ksort.h"
#include "htslib/hts.h"

/* Compile and link with
        gcc -o foo foo.c libhts.a -lbz2 -llzma -lz
*/

typedef struct {
    int x;
} foo;

#define bar(a,b) ((a).x < (b).x)

KSORT_INIT_GENERIC(uint16_t)
KSORT_INIT(_off, foo, bar)
KSORT_INIT(_off_max, foo, bar)

int main() {
    hts_version();  // pull in hts.o
    errmod_cal(NULL, 0, 0, NULL, NULL);  // pull in errmod.o
}

This fails to link due to 24 duplicate ks_* functions, as the ksort usage in errmod.c and hts.c uses non-hts_-prefixed public namespace functions. It would be possible to make those HTSlib source files use ksort functions with names like …_htslib_internal_… which would not collide with sensible third-party code, but it's about as easy to add static support to htslib/ksort.h.

See also PacificBiosciences/pbmm2#11 (via this tweet); if static ksort had been available, this would have been a good way to fix this rather than renaming away from the collision.

[daviesrob]

Thanks. All good for minimising our symbol leakage. Which reminds me that we should also put in a fix for #693 as well (that one is about kstring).

[jmarshall]

Cheers. Re that kstring one: I reckon HTSlib is the 800-pound gorilla here, and that one should be worked around inside libbwa.