Patch for different result returned by Reader.fetch() and iteration over Reader

I stumbled on this behavior when parsing VCF files with `\r\n` line endings which was returned from a 3rd party web server. The problematic VCF line is below:

    chr1	14653	.	C	T	61.42	PASS	AC=2;AF=1.0;AN=2;DP=4;Dels=0.0;FS=0.0;HaplotypeScore=0.0;MLEAC=2;MLEAF=1.0;MQ=21.09;MQ0=1;QD=20.47;VQSLOD=-inf;culprit=DP;GATKCaller=UG,HC	GT:AD:DP:GQ:PL	./.:.:.:.:.	1/1:0,3:3:9:87,9,0	./.:.:.:.:. 

The line above (with '\r\n' line ending) can be parsed just fine if I iterate over the `vcf.Reader`. However, when I used `Reader.fetch()`, I stumbled on this error:

```
  File "<string>", line 1, in <module>
  File "/home/bow/devel/repos/public-contrib/PyVCF/vcf/parser.py", line 595, in fetch
    return self.next()
  File "/home/bow/devel/repos/public-contrib/PyVCF/vcf/parser.py", line 567, in next
    samples = self._parse_samples(row[9:], fmt, record)
  File "/home/bow/devel/repos/public-contrib/PyVCF/vcf/parser.py", line 438, in _parse_samples
    self.samples, samples, samp_fmt, samp_fmt._types, samp_fmt._nums, site)
  File "cparse.pyx", line 55, in vcf.cparse.parse_samples (vcf/cparse.c:1505)
ValueError: could not convert string to float: .
```

After digging a bit deeper, I found out the problem was the line ending *combined* with the `.` character. The short circuit at [L453](https://github.com/jamescasbon/PyVCF/blob/master/vcf/parser.py#L453) does not return immediately since the character is `.\r` instead of `.`. If the last sample of the record has some values, this does not happen because e.g. `float("25")` and `float("25\r")` both return `25.0`.

I have not checked this on Windows (I am on Linux), but I would not be surprised if this behavior doesn't happen in Windows since `\r\n` is expected.

Anyway, this is a very simple fix for the problem. No test cases yet, but let me know if I should add them :).