* Pass LocalBuilders instead of indexes since ILGenerator already optimizes the opcode used

* Eradicate magic local indexes to make refactoring safer

* String and byte[] tuple elements cause InvalidProgramException

* Stop setting current index local which is nonexistent in ValueTuple deserializer

* prep work for adding Microsoft.Data.SqlClient support/tests; SqlClient dependency is not yet removed

* Failing tests for tuples larger than 7

* Special-case IL generation for ValueTuple

* Make value-processing logic available to ValueTuple generation

* fix #1228 - rev sqlclient to 4.6.0
* use transitive deps for SqlClient

When reading Geometry and Geography values from the database, we need to specify the SRID explicitly to retain it in the DbGeometry / DbGeography type. (#1038)

merging, thanks, and sorry for delay

thanks, appreciated

This bumps and locks at 1.60.0 to cope with whatever binding policies .NET Core is enforcing - then we can stick at this until 2.x I guess.

This PR is for the issue I raised earlier #1194 

- I've added links for all every issue
- Tidied up capitalization 

Let me know if you need me to make any changes

In cases where the object has a property named ID, the property will automatically be assigned as [Key], even if [Computed] is added manually in an attempt to override it. This can cause confusion, this exception will be thrown despite the code looking fine and there only being one [ExplicitKey] defined. I've added this extra line of information to help diagnosis.

Fixes #620

Added a section to indicate Dapper works well with User Defined Variables.

Lots of runs is good, but changed behavior and greatly affects stability (due to GC).

Adds Dashing benchmarks to Dapper.Tests.Performance

Added Linq2DB benchmarks

This is prepping a run we can drop into the README easily. And more info on allocations and such along with it. It's finishing off the benchmark port getting it into a good output state (something we can copy/paste). It removes Simple.Data because the package was debug and causes a lot of issues.

This doesn't output 100% like we want yet (fastest to slowest). BenchmarkDotNet joins summary results after ordering...we need to post-order that. I'm asking the maintainers how to do so.

Also note Belgrade was not parameterizing before, giving it a huge unfair advantage. This has been fixed to be apples:apples.

MySql.Data is a travesty at this point - moving to something more stable. Really we weren't testing Dapper with previous test failures, we were testing what mood MySql.Data and NuGet extraction are in and which phase of the moon is about.

Also speeds up the builds with 1 restore and 1 build. We can simplify here because everything is relevant (no wasted builds).