Trimfq bugfix

This corrects a bug in trimfq, where entire runs of low quality characters like `#` would not be trimmed. Here is an example with 28d56a3, using the following file as `bug.fq`:

    @bug
    NNNNTTTCTAGTCAACTTGANNNNNNNNNNNNNNNNNNNNNNNNNNNNCNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
    +
    ####################################################################################################

    ./seqtk trimfq bug.fq
    @bug
    NNNNTTTCTAGTCAACTTGANNNNNNNNNNNNNNNNNNNNNNNNNNNNCNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
    +
    ####################################################################################################
    ./seqtk trimfq bug.fq # new-version
    @bug
    NNNNTTTCTAGTCAACTTGANNNNNNNNNN
    +
    ##############################


Since there is no variation in base quality in these extremely bad quality reads, the window-based trimming isn't triggered. I just take the first `max_len` bases (not removing entirely so read pairing is not broken) when the value of `max` is not set (still being 0 from initialization) because `s` is never greater than 0.