Add channel.advancePastByte, use it to improve revcomp

[mppf]

PR #8045 added some messy rev-comp studies that improve performance by improving the I/O pattern. What the performance comes down to is two things:

1. Copying large chunks of the input from the channel buffer in to the array to be used
2. Using memchr to identify the relevant chunks of the input

I experimented with a version that used regexp format strings to replace the memchr call but that had unsatisfying performance.

This PR adds channel.advancePastByte in order to enable the expression of the fast I/O pattern in revcomp easily. Now the revcomp version does the following:

• "mark" (indicate to the I/O system not to drop the buffer as we might return)
• identify the offset of the newline (end of the sequence description)
• identify the offset of the > (start of the next sequence)
• "revert" (go back to where we "marked")
• read the data again in one go with readBytes

I'm seeing a 10% speedup for this version beyond revcomp-buf.chpl, and it is much simpler.

While there, I noticed that qio_channel_advance might not set up the buffer in some cases, so added code to do that.

• full local testing
• docs for advancePastByte
• update catch statement to specify type
• check for 32-bit issues ala Fix 32-bit revcomp failures #8116

Closes #8105.

Reviewed by @benharsh - thanks!

[psahabu]

Does the compiler currently support this pattern? I think it should, but right now it might need to be catch e: UnexpectedEOFError.

[mppf]

seems to work...

[mppf]

I bet that it's not matching on the type but rather I'm naming an error variable UnexpectedEOFError and it shadows the type. I.e. it's like I wrote catch e. I'll update it.

[bradcray]

Stab in the dark to head off potential testing noise: does the need for PR #8116 have any implications for this one?

[mppf]

@benharsh - could you review this PR? we certainly talked about it. It passed full local testing in an earlier version - after review I plan to run that again. Thanks.

[benharsh]

Nice!

Some potential follow-up issues to think about:

• This pattern feels different enough from other languages to warrant some kind of simple example somewhere.
• It would be nice if we could pass arrays (at least DefaultRectangular) to channel.readBytes. This is probably a pretty simple change.

[mppf]

@benharsh - not sure where to put an example but at least it's a documented function...

As far as adjusting readBytes, I made a note of that issue #7954.