Type mapper enhancements

In Dapper the SqlMapper is a static entity which maps types to db columns. There are a couple of use cases which are problematic to handle with the normal Dapper mapping mechanism.

When considering new APIs for DapperAOT it would be great if there could be a mechanism to support these use cases.

Mapping Validation

In a large application it is useful to validate that mappings are correct and complete. This type of validation typically can be excluded for production versions but is useful for test and development.

Validation type 1: All db columns have properties

In original Dapper a custom converter can be used which throws an exception when a db column is encountered for which there is no property. This caters for this type of validation.

Validation type 2: All properties have db columns

This is not possible to do with the current dapper. The reason for this is that the mapper is fully static so it is not possible to store any context specific data for a specific conversion. If the sqlmapper were not static (i.e. if we had something like the DapperPlus Context then it would have been possible to do.

Start with the SqlMapper entry point and the DapperAOT API discussion described in the issue. Review how custom converters handle unmapped database columns and how static mapping limits validation context. Done would require an agreed mechanism covering both validation types, including properties without database columns.