Reader.fetch uses zero-based, half-open coordinates.

These changes make the behavior of Reader.fetch consistent with with
pysam.Tabixfile, which uses the zero-based, half-open coordinate system
for Tabixfile.fetch. See
http://www.cgat.org/~andreas/documentation/pysam/api.html#pysam.Tabixfile.fetch

Previously, PyVCF's Reader.fetch declared no particular coordinate
system. Since the method quietly deducted 1 from the start position,
apparently it assumed users were going to input a one-based coordinate
there. However, users familiar with pysam's Tabixfile for other formats
get an unexpected surprise when variants ahead of the start coordinate
start getting returned by Reader.fetch.

As _Record.start and _Record.end are in the ZBHO coordinate system, it
adds to the consistency that fetch take start and end coordinates in
ZBHO, so the same _Record instance could be retrieved using its .CHROM,
.start, and .end coordinates.

This change also removes the prior behavior of fetch of returning a
single _Record instance if given only chrom and start coordinates, by
implicitly doing a Tabixfile.fetch(chrom, start-1, start). The new
behavior when omitting the end parameter is to return an iterator of
_Record instances starting at start and continuing through the end of
the chromosome chrom. Again, this is the behavior consistent with
pysam.Tabixfile.fetch, and is what users ought to expect.

This change also allows the user to omit both the start and end
positions. In this case, an iterable of _Record instances for all
records for the particular chromosome chrom will be returned, which
again, is consistent with Tabixfile.fetch. This behavior also resolves
Issue #123 "Cannot fetch() whole chromosome".
Merge pull request #156 from gotgenes/feature-zbho_tabix_coordinates

Use zero-based, half-open coordinates for Reader.fetch