Small performance enhancements for cut: bytes cutting

Several small performance enhancements.

For very large, or infinite ranges, `uutils cut` bytes cutting is now 3 times faster than `GNU cut`.

    $ ranges=1-
    $ perf stat -r 10 build/cut -b $ranges `find /boot -type f -readable` >/tmp/uucut
    ...
    0.095898887 seconds time elapsed ( +-  0.14% )
    $ perf stat -r 10 cut -b $ranges `find /boot -type f -readable` >/tmp/gcut
    ...
    0.308146576 seconds time elapsed ( +-  0.24% )

    $ ranges=4-6,3-8,20-30,15-25,23,6
    $ perf stat -r 10 build/cut -b $ranges `find /boot -type f -readable` >/tmp/uucut
    ...
    0.102587877 seconds time elapsed ( +-  0.07% )
    $ perf stat -r 10 cut -b $ranges `find /boot -type f -readable` >/tmp/gcut
    ...
    0.179558780 seconds time elapsed ( +-  0.06% )

    $ ranges=-4097
    $ perf stat -r 10 build/cut -b $ranges `find /boot -type f -readable` >/tmp/uucut
    ...
    0.095640648 seconds time elapsed ( +-  0.13% )
    $ perf stat -r 10 cut -b $ranges `find /boot -type f -readable` >/tmp/gcut
    ...
    0.305291892 seconds time elapsed ( +-  0.24% )

For relative performance improvement see issue #345.
I think it's alright to use `unsafe` code so long as:

1. The code is in actuality safe (_e.g._ won't go out of bounds).
2. The code is noticeably faster.
3. `unsafe` is used sparingly.

This seems to fit those requirements.