Fix handling of invalid bytes in stream decoders

[Lysxia]

This is a different bug that I found while troubleshooting #525. When we have 4 bytes buffered and they are invalid (whether in UTF8, 16, or 32), we skip the first byte, but the following (fifth) byte was being discarded instead of added to the end of the buffer. Interestingly, this bug and #525 have been around since 0.3.

This includes the commit from #527 because the changes are next to each other so there would be a conflict to resolve anyway. Rebasing should remove it.

[Lysxia]

The broken test suggests that the strict decodeUtf8With is also buggy when the flag simdutf is disabled.

         t_decode_utf8_lenient:                                FAIL (0.01s)
          *** Failed! Falsified (after 99 tests and 55 shrinks):
          ["!\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL","\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\128\NUL"]
          "!\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\65533\NUL" /= "!\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\128\NUL"

Update: I can't reproduce the bug on my linux machine.

[Bodigrim]

LGTM, please rebase.

Update: I can't reproduce the bug on my linux machine.

I raised a separate ticket #529 to investigate.