OSX newlines do not seem to be handled properly by FASTQ parser

Enze, can you check the processing of fastq files such as (look at the newlines indicated with 'a0', (`man ascii`)):

```
00000030  20 20 31 30 31 4d 0a 54  41 54 47 47 47 43 41 47  |  101M.TATGGGCAG|
00000090  41 41 54 54 47 43 54 54  41 47 54 54 0a 2b 0a 47  |AATTGCTTAGTT.+.G|
000000a0  47 47 47 3d 47 46 47 43  47 47 47 47 40 47 41 3d  |GGG=GFGCGGGG@GA=|
00000100  45 47 46 41 0a 40 46 72  61 67 5f 32 20 63 68 72  |EGFA.@Frag_2 chr|
00000130  31 33 32 39 37 38 29 20  20 31 30 31 4d 0a 41 54  |132978)  101M.AT|
000001a0  43 54 54 0a 2b 0a 39 44  26 47 45 44 47 46 42 42  |CTT.+.9D&GEDGFBB|
00000200  40 38 2b 43 43 3e 38 40  3c 39 40 0a 40 46 72 61  |@8+CC>8@<9@.@Fra|
00000240  31 30 31 4d 0a 41 43 41  41 41 54 54 43 41 41 41  |101M.ACAAATTCAAA|
```

It seems that the `check_fmt` logic does not treat it properly and always returns 0 reads on OSX :/

```
void read_process (bloom * bl, Queue * info, Queue * tail, F_set * File_head, float sampling_rate, float tole_rate, char mode, char fmt_type)
(...)
	if (next_job == NULL)
		return;
```

```
char *check_fmt (Queue *info, Queue *tail, char *start_point, char type)
(...)
        { // XXX: Does this account for OSX-style newlines? next_job is always NULL on OSX fastq files.
                next_job = strchr (start_point, '\0');
                if (next_job[-1] == '\n' && next_job[-2] == '\n')
                        next_job -= 1;
                else if (next_job[-4] == '\r' && next_job[-3] == '\n')
                        next_job -= 2;
        }

```

@guillermo-carrasco