Add ability to pass additional TypeHandlers to Query methods

We are currently refactoring a massive platform that we inherited from another company, and as part of that we are removing EF and updating it to use Dapper. Whilst doing so, we have found a major 'chicken & egg' problem caused by the fact that the TypeHandlers collection is a global static collection while trying to move some collections over to Dapper whilst maintaining compatibility with EF for other parts of the platform that we cannot yet fully refactor.

We have types that we would like to handle via a TypeHandler because there are occasions where the value is returned as a value that we then have to "decode" to get the entity, but when we register it, it causes problems elsewhere in the code that cannot use that TypeHandler because the entity is returned as a datatable.

We cannot remove the TypeHandler for just these calls because it's a static collection and breaks the calls to the methods that require them, and calls that could require the TypeHandler could be occurring in parallel on other threads (which is exactly what we are seeing).

It would seem a logical solution to allow the Query...Async methods to pass in a list of additional TypeHandlers to allow on a per-query basis where registration of those TypeHandlers globally would cause issues.

Either that, or a mechanism to allow a TypeHandler to return something indicating that "I can't handle this" (or throw a custom Exception that can be caught by Dapper to signify the TypeHandler doesn't know how to handle what it's been given), and allow the default DataTable type handler to take over instead.

Start by examining the Query...Async methods and the global TypeHandlers collection described in the issue. Compare the proposed per-query handlers with the fallback DataTable behavior; done means a clear, thread-safe mechanism is defined and covered for both handler and non-handler queries.