The original code would always add one extra downstream base to
the slice (for genes on the forward and reverse strand).

Correcting this implies that cached slices will not be used by
new queries requesting the exact same gene and number of upstream
and downstream bases, effectively invalidating them.

However, most existing cache entries affected by this bug will be
on GRCh37/hg19, whereas current slices by gene name will yield
GRCh38/hg38 slices.

The only cache issue I see is trying to use existing cache
entries created by slicing by gene name, by re-slicing by
explicit coordinates instead of gene name. To get the old cache
entry one would have to add an extra downstream base.