perf: Optimize async method allocations

[Wraith2]

This is a rework of a closed PR from corefx, dotnet/corefx#37254 and I wrote a small essay explaining why it was a good idea in the initial post for that so it's worth clicking through and reading it.

Profiling the DataAccessPerformance project which emulates the TechEmpower fortunes benchmark you can see that some of the top allocations are state closures for async methods like ReadAsync GetFieldValueAsync. Investigating this I found the code to be much more complex than I'd expected and quite confusing. In order to reduce the allocations I reworked the async infrastructure to use concrete classes and then cached some which are used repeatedly.

Before:

After:

DataAccessPerformance results:

name	sync	threads	TPS	stdev	description
ado-sqlclient+async+128	async	128	64667	3262	master
ado-sqlclient+async+64	async	64	69262	1592	master
ado-sqlclient+async+32	async	32	68814	1918	master
ado-sqlclient+async+128	async	128	67288	1595	branch
ado-sqlclient+async+64	async	64	68870	2395	branch
ado-sqlclient+async+32	async	32	68311	1949	branch

Which shows a ~5% throughput improvement in situations where CPU time is a limitation and less improvements where it isn't a limitation. I recommend reviewing manually because the diff makes the large number of changes and the extraction of lambdas look particularly confusing.

[David-Engel]

I like the new structure better and I can't see anything obviously wrong. But I'll admit, it's hard to follow async logic in here and the changes are significant enough to not compare well. If we get this in now rather than later, hopefully we'll have time to catch any regressions that might slip through the tests. I'm impressed that you can get your head wrapped around the details well enough to bite off these perf optimizations. I appreciate the work you put into them!