Notice: Probably just use Sep instead

[airbreather]

Even in the use cases that spawned this library, Sep seems to be more efficient than Cursively in practically every way. Specifically, Sep has a reader benchmark that it calls "Floats", and the best Cursively implementation I could come up with quickly is quite a bit slower, though Cursively still had a significant (relative) edge in heap allocations.

Even with heap allocations, despite Cursively's massive lead (relatively speaking), it's still just a difference of a few kilobytes for tens of thousands of rows (contrast with CsvHelper, where even recent versions allocate about a couple dozen megabytes), and those few kilobytes should certainly be low enough for any imaginable use case.

There are some techniques that I could use to close the gap in newer .NET versions, but honestly, I just don't feel like it. Sep's "Floats" benchmark runs at like 1 GiB/s, so as far as I'm concerned, it's just not worth my time to improve on that. Especially since even in the best-case scenario for Cursively, the usability is just horrendous.