Features/emumeration optimizations

[steve7411]

These changes reduce an O(n^2) enumeration for the common case of string inputs to O(n), amongst a few other things. I changed MatchState to create a Slice in any case where the input isn't already an IList, and Slice is now a thin wrapper around adapters that implement IList. I tried not to change publicly exposed API much, but MatchState's Input property is read only and I didn't keep Slice's copy on write since it isn't currently used anywhere.

The benchmark project is currently just using the Calc sample parser, so it's mostly exercising input classes and string input, but I was able to get a good increase in performance with these changes on an input with around 10,000 numbers:

Before:

Method	Job	Runtime	Mean	Error	StdDev	Ratio
CalcParserBenchmark	.NET 5.0	.NET 5.0	8.659 s	0.0613 s	0.0512 s	0.91
CalcParserBenchmark	.NET Core 3.1	.NET Core 3.1	8.764 s	0.0649 s	0.0607 s	0.92
CalcParserBenchmark	.NET Framework 4.8	.NET Framework 4.8	9.551 s	0.1052 s	0.0821 s	1.00

After:

Method	Job	Runtime	Mean	Error	StdDev	Ratio
CalcParserBenchmark	.NET 5.0	.NET 5.0	899.6 ms	4.99 ms	4.16 ms	0.79
CalcParserBenchmark	.NET Core 3.1	.NET Core 3.1	1,002.2 ms	8.04 ms	7.52 ms	0.87
CalcParserBenchmark	.NET Framework 4.8	.NET Framework 4.8	1,145.5 ms	9.61 ms	8.99 ms	1.00

[chalcolith]

Sweet, thanks @steve7411! May I ask how you found IronMeta and what you're using it for?

[steve7411]

I read about it in an article I found when I was searching for C# parser generators. I'd never heard of OMeta before, and it looked nice. I'm currently using it for an interpreter for a very old version of BASIC that was originally for CP/M.