The string colorizer is slow (but apparently only the first time it runs, for some reason?), printing can be slow, who knows what else the framework is doing, etc., so manually inserting Stop()s exactly where we want the timings to stop is the most reliable way to handle this. I like the elegance of the disposable solution, but my goal here is to measure the actual algorithm, not anything else.
A slightly restructuring would make it so I don't have to do this; if main.cs was receiving a string from Part1 and Part2 instead of having each day individually print its own results, we could scope timings to exclude any console writing. But whatever.
I also went ahead and made 17 only run once since I was using the same result to answer part 1 and 2. I've since discovered that part 1 is far simpler and can be found without solving the entire problem space, but whatever.
This is a small low-hanging fruit pass. I was really just curious where the time was going since I didn't feel like the algorithm was actually expensive. Turns out it's not, really...the larger cost is setting up the frequencies and pairs collections, and computing min/max was 9x more expensive than it needed to be (I was expecting 2x since I was iterating over the collection twice, but 9x is...unreasonable, so I just unrolled it myself). It also turns out that MinBy() is marginally slower than Min() with no gain (for this use case), so that was an easy win on the brute force solution.
