Commit e495718 changed bgzip from unix raw POSIX read() calls to
hread().  Unfortunately hread gets its buffer size from stat of the
input file descriptor, which can be 4kb for a pipe.  We're reading
0xff00 bytes, so this ends up being split over two reads mostly, with
one or both involving additional memcpys.  This makes the buffered I/O
worse performing than non-buffered.  In the most extreme cases (cat
data | bgzip -l0 > /dev/null) this is a two fold slow down.

The easy solution is just to increase the buffer size to something
sensible.  Currently we play it cautiously and only do this on pipes
and fifos.

Fixes samtools#1767

On AMD EPYC 7713 aligning to cache size boundaries makes a very
significant difference to fp->backend->read performance in the
kernel.  A modern Intel CPU did not demonstrate this difference.

x86 often have cache line size of 64 bytes, and apple Arm chips 128
bytes.  I haven't tested if Arm benefits from alignment during read
calls, but we can check size with sysconf(_SC_LEVEL1_DCACHE_LINESIZE).
However to avoid additional autoconfery I just picked 256 as it gives
us headroom and is simple.

Speed ups on the AMD EPYC:

time bash -c 'for i in `seq 1 30`;do cat < ~/lustre/enwik9| ./bgzip -l5 -@32 > /dev/null;done'

Unaligned
real    0m45.012s
user    10m7.661s
sys     0m58.770s

Aligned
real    0m30.717s
user    11m14.004s
sys     0m32.921s

It is likely this could improve other bits of code too.