Stream sequences should double-buffer

[Whiteknight]

Streaming sequences should be able to have two buffers and switch between them more easily. That way if we are frequently reading/rewinding/peeking around the boundary of two buffers we will not need to frequently refill.

We would probably need to keep track of the start position of each buffer in some way, so we would know if the "next" buffer was the correct one to move to or if we needed to refill. A rewind could also check the buffer start location of both buffers to know which one to rewind to.

[Whiteknight]

I have started a branch to work on this, and added a benchmark harness to test possible optimizations.

So far the double-buffer implementation is showing significantly fewer buffer fills than the single-buffer implementation, but the overall runtime performance is (marginally) slower. I'm still trying to figure out where the bottleneck is.

[Whiteknight]

I am removing this from the v5 milestone. We will still look into it, but we won't do it for v5

[Whiteknight]

Situation: I have added a double-buffered implementation of StreamSingleByteCharacterSequence, which works well and passes tests. HOWEVER, I have tried doing the same for StreamCharacterSequence and have hit a roadblock.
In FillBuffer() we expect to just be able to read the stream from the current position, but that current position might not be correct if we've done some rewinds to previous buffers and then back. I'm still trying to work out the precise set of steps that cause it, but we lose the current position of the stream and cannot read forward to the next buffer correctly.
This problem might be correctable, but it's a lot of work and I don't know if it's worth it at this time.

[Whiteknight]

I've managed to come up with an implementation for StreamCharacterSequence which does pass tests. However, I added in cases where we could not simply switch to the next buffer N unless we had already read buffer N+1 and kept track of the start position of N+1. Otherwise there's no way that I can currently see to set up the buffer position so the next call to FillBuffer() will read from the correct position. I'm not certain that this is much of an optimization, since a lot of back-and-forth churn will happen towards the high-water mark of the parse and not back several buffers-worth.