This adds a netstandard2.0 build to Dapper (and StrongName until v2),
adds a netstandard2.0 test lineup, restores most functionality (except
UDTs for SQL, e.g. .UdtTypeName isn't in netstandard2), and also breaks
things not actually implemented or implemented correctly in
netstandard2.0. Pushing this up so we can work through these with the
.NET teams.

Several things are still broken here (and fail tests):
- Parameter decimal values (not filed yet)
- DataTables as parameters
(https://github.com/dotnet/corefx/issues/19708)
- .GetSchemaTable() (not yet filed, implementation is completely missing
from SqlDataReader in CoreFX)

While the compile is clean, the above are runtime issues.
`SqlParameter.UdtTypeName` is a separate issue, that one just wasn't in
`netstandard2.0` at all...so we can't support UDTs there until it is.
See https://github.com/dotnet/corefx/issues/17126 for details.

This is based on BenchmarkDotNet (while preserving the legacy format
with minor improvements as well - legacy runs much faster). See #666 for
details. Not an ominus number at all.

Note: this code will get a bit simpler with BenchmarkDotNet categories,
see https://github.com/dotnet/BenchmarkDotNet/issues/248 for details.

It's indeed broken on their end. We should consider switching providers,
e.g. https://github.com/mysql-net/MySqlConnector/

* Progress on VS 2017 build tooling
* Finally, a working VS 2017 tooling build

Add tests for the too few/too many columns scenarios for value-tuples; happy to discuss alternative expectations

Better matching of value-tuple names when wrong number of columns - should return nulls for unmapped

Under the `List Support` section, the sentence opens with `Dapper allow you`, which should instead be `Dapper allows you`. This PR will correct this mistake, restoring balance to the universe.

After originally spotting this, the most minor of mistakes, I decided to leave it and move on with my life, since it likely effected nobody. Four hours passed and the thought that it existed unchecked had fully manifested itself within my subconscious and I was no longer able to continue with my existence knowing that I had seen this mistake and not exercised my power to correct it.

Thank you, and sorry.

Due to the way VS test works (by injecting an executable entry point), the performance tests needed to be factored out. I also organized all of our existing tests better along the way.
Actual code changes to Dapper itself are very minor, only formatting and documentation fixes (which we need many more of).

The build.ps1 script is upated to work, but note that <frameworkAssemblies> is not working in .nuspec inside the packages in the new .csproj system. I consider this to be a blocker. Issue is here: https://github.com/NuGet/Home/issues/4853

* Added fix for Simple.Data tast

Due to the missing .FirstOrDefault() in Simple.Data test, performance
numbers for Simple.Data were too high (better than hand coded data
reader). Added FirstOrDefault() to actually fetch the data.