A simple test script to show Freebayes' buggy region/target handling

The script first shows the correct output of various VCF + BED tools and
then runs variations on Freebayes to demonstrate the improper handling
of region coordinates on the command line and in BED files.
Revert "change to help text to reflect region spec change"

This reverts 0595cc5.

The current region handling (and also that before this change was made)
includes the end position internally but expects positions that exclude
it when reading --target BED files or parsing --region specs.
Correct a bunch of off-by-one errors related to targets/positions

A number of previous commits which switched the internally-used position
numbering were not comprehensive.  This lead to a clear inconsistency in
position handling that resulted in mishandled edge cases.

I audited the code for all uses of left and right boundaries, as well as
currentPosition.  While it's quite possible I still missed a couple
spots, this commit fixes a number of places missed in previous commits.
Most of the code, and the intent described in the latest commit
messages, uses 0-based, fully-closed positions internally (e.g. 0-1
describes the first two bases).  This is different from the external
expections of BED and chr:X-Y positions, which both use 0-based,
half-open positions (e.g.  0-1 describes just the first base).

I attempted to normalize all such internal arithmetic and comparison to
expect 0-based, fully-closed positions, while still expecting the standard
0-based, half-open positions from user input.  The edges of freebayes
convert to the internal representation as soon as possible to avoid
leaking the external representation.

Debugging and error messages printed to the user regarding
targets/regions are normalized to be in the 0-based, half-open style so
they match the input the user may have given.  Debugging and error
output regarding currentPosition still mixes reporting 0-based numbers
with 1-based numbers.  It appears to fall more or less along the lines
of "am I reporting about a target (0-based)?" vs. "am I reporting about
a VCF position (1-based)?", but the utility of the trace logs and other
debugging output is unclear to me, so I left it alone for now.  I
audited the two cases using the following greps:

    git grep -P '<<[^<]*?currentPosition(?!\s*\+\s*1)'
    git grep -P '<<[^<]*?currentPosition(?=\s*\+\s*1)'

It's worth noting the hunk in this commit which removes a check on
parameters.allowIndels, because this parameter previously affected
internal position tracking in interesting ways: when enabled, positions
were incremented by 0.5 (half a base) during each cycle.  This code was
removed in 6835a00, however, which is good since it added notable
complexity to position comparisons.
Hand tabix 1-based, fully closed regions when calling setRegion

This affects --variant-input and --haplotype-basis-alleles.
Merge pull request #110 from MullinsLab/target-positions-off-by-one

Correct a bunch of off-by-one errors related to targets/positions