Revert "Trying khmer (probably doing it wrong, fails)"

This reverts commit 36835618d0ec476e1239b35823caecf657cb4156.
Fix inconsistency in error function's name
Quick FASTQ interlacer for testing Bloom filter script

The paired FASTQ files I want to use are from the ENA, and come as two (gzipped)
FASTQ files. Interestingly the ENA assigns their own read names without /1 and /2
but preserves the original read names (with their /1 and /2 in the FASTQ title
line). Therefore this interlace file copes with that, and adds the /1 and /2.

$ time ./interlace_fastq.py ERR123956_1.fastq.gz ERR123956_2.fastq.gz | ./blooming_reads.py -c all_mito.fas -f fastq -k 20 > /dev/null
Hashing circular references in all_mito.fas
Set and bloom filter of 20-mers created (79972 k-mers considered, 48864 unique)
Using Bloom filter with capacity 48864 and error rate 0.01
Building filters took 0.1s
Interlacing ERR123956_1.fastq.gz and ERR123956_2.fastq.gz
Decompressing ERR123956_1.fastq.gz
Decompressing ERR123956_2.fastq.gz
Interlacing paired FASTQ files to stdout...
Processed 100000 reads, kept 2158 (2.2%), taken 3.2s (of which 2.2s in filter)
Processed 200000 reads, kept 4348 (2.2%), taken 6.3s (of which 4.4s in filter)
Processed 300000 reads, kept 6558 (2.2%), taken 9.4s (of which 6.6s in filter)
Processed 400000 reads, kept 8758 (2.2%), taken 12.5s (of which 8.9s in filter)
Processed 500000 reads, kept 10926 (2.2%), taken 15.6s (of which 11.1s in filter)
Processed 600000 reads, kept 13014 (2.2%), taken 18.7s (of which 13.3s in filter)
Processed 700000 reads, kept 15220 (2.2%), taken 21.8s (of which 15.5s in filter)
Processed 800000 reads, kept 17302 (2.2%), taken 25.0s (of which 17.7s in filter)
Processed 900000 reads, kept 19404 (2.2%), taken 28.1s (of which 19.9s in filter)
Processed 1000000 reads, kept 21632 (2.2%), taken 31.2s (of which 22.2s in filter)
Processed 1100000 reads, kept 23844 (2.2%), taken 34.3s (of which 24.4s in filter)
...

With the equivalent unaligned BAM file (the raw reads as submitted to the ENA),
the final counts should match (running now) and the timings very close. The read
order differs between the files, so the partial counts differ.

$ time samtools view 7261_6.bam | ./blooming_reads.py -c all_mito.fas -f sam -k 20 > /dev/null
Hashing circular references in all_mito.fas
Set and bloom filter of 20-mers created (79972 k-mers considered, 48864 unique)
Using Bloom filter with capacity 48864 and error rate 0.01
Building filters took 0.1s
Processed 100000 reads, kept 2162 (2.2%), taken 3.0s (of which 2.3s in filter)
Processed 200000 reads, kept 4406 (2.2%), taken 6.0s (of which 4.5s in filter)
Processed 300000 reads, kept 6630 (2.2%), taken 9.0s (of which 6.8s in filter)
Processed 400000 reads, kept 8796 (2.2%), taken 12.0s (of which 9.0s in filter)
Processed 500000 reads, kept 10982 (2.2%), taken 15.0s (of which 11.3s in filter)
Processed 600000 reads, kept 13140 (2.2%), taken 18.0s (of which 13.5s in filter)
Processed 700000 reads, kept 15322 (2.2%), taken 21.0s (of which 15.8s in filter)
Processed 800000 reads, kept 17474 (2.2%), taken 24.1s (of which 18.0s in filter)
Processed 900000 reads, kept 19688 (2.2%), taken 27.1s (of which 20.3s in filter)
Processed 1000000 reads, kept 21926 (2.2%), taken 30.1s (of which 22.5s in filter)
Processed 1100000 reads, kept 24086 (2.2%), taken 33.1s (of which 24.8s in filter)
...
Processed 268400000 reads, kept 5849364 (2.2%), taken 7958.6s (of which 5942.2s in filter)
Processed 268500000 reads, kept 5851536 (2.2%), taken 7961.6s (of which 5944.4s in filter)
Running filter took 5945.3s, overhead 2017.5s, total 7962.8s
Kept 5852496 out of 268540706 reads

real 132m42.969s
user 145m1.438s
sys  1m19.550s

We can check the BAM read count easily with grep,

$ samtools view 7261_6.bam | grep -c -v "^@"
268540706

Similarly each of the FASTQ files had 134,270,353 reads, making 268,540,706 reads
in total:

$ cat ERR123956_1.fastq.gz | gunzip | grep -c "^@ERR"
134270353
$ cat ERR123956_2.fastq.gz | gunzip | grep -c "^@ERR"
134270353

By eye the file contain similar read names, but in a different order.
So, the FASTQ filter (and the FASTQ interlacer) seem to work fine.
Comment changes, adding a TODO list