Allow reading streams with incompatible encodings

[airbreather]

The idea of only supporting streams that look like ASCII could hypothetically be a bit limiting.

Technically, nothing's stopping us from exposing a TextReader-based API and decoding to UTF-8 on-the-fly so that it can work with the rest of the Cursively ecosystem.

This would hypothetically be useful for use cases where someone's been using Cursively for a while without issues, but then it turns out that they need to handle something esoteric and don't want to either convert everything over to something like CsvHelper or sacrifice Cursively's superior performance in common cases.

[airbreather]

Technically, nothing's stopping us from exposing a TextReader-based API and decoding to UTF-8 on-the-fly so that it can work with the rest of the Cursively ecosystem.

Well... if we're going to get technical about it, there's also nothing stopping us from exposing an entire parallel stack with ReadOnlySpan<char> at the core instead of ReadOnlySpan<byte>.

I don't think that's worth doing either, since we would need a parallel stack of everything, including the visitors, inputs, and whatever happens for #12... unless I come up with an abstraction that lets some stuff be shared, which makes it even more expensive to develop.