In a bid to keep the DEBUG_printf line potentially printing up the
value of 'i', while also avoiding the complaints about 'i' being set but
unused, I changed the code to also handle potentially wide
characters.  (I haven't tested it works actually with wide characters,
but it'll be better than before and the main goal was the silence the
annoying warning!)
Fix a bug where hts_set_fai_filename() didn't pass this through to
CRAM.  It appears this bug has been long standing, since
https://github.com/samtools/htslib/commit/2402fc00fe1f2360cd9056173045f65bc0b683dc,
but was not detected due to the tests finding the reference via a UR:
@SQ tag instead.

Also amended the CRAM referencing handling code to handle bgzf at the
same time.  Ideally we would rip out a lot more code from cram_io.c
and replace it with more calls to faidx.c instead, but that can be the
subject of another update.
Fix bug spotted by valgrind when running "./test_view -D
ce#unmap.tmp.cram".

Normally the header is nul terminated, but in this case the header is
zero bytes long, leading to malloc(0) and a later strlen() of that
block.  We now forcibly always allocate +1 byte and nul terminate the
buffer, avoiding the issue and better coping with a potential cram
corruption too.
Fixed an error found via valgrind of test_view -D c1#pad1.tmp.cram.

The extra_len field for bam_construct_seq didn't include the +1 for
nul terminating the aux string.  I am unsure why this didn't crop up
in other files.
Reverting 9e844e0be26875d29b6e2c853c2b4d02c4f1faa4 and rewriting in a
better manner.

Passing +1 to the extra_length in bam_construct_seq causes the length
of data in the bam structure to be +1, and then causes bam decoding to
have issues in some cases.

The correct solution made here is simply to remove the nul terminating
of the auxiliary block.  It's a hang-over from the io_lib days and
isn't necessary.