Add TypeMapperBuilder to use Dapper without setting Attributes on Model classes

[vantheshark]

For classes that we can not change to add attributes
Usages:

public class VehicleMapper : TypeMapper<Vehicle>
{
    public VehicleMapper()
    {
        this
            .TableName("Automobiles")
            .For(x => x.Computed).Computed();
    }
}
TypeMappers.Register(new VehicleMapper());

OR

TypeMappers
    .MapType<ObjectXWithoutAttribute>()
    .TableName("ObjectX")
    .For(x => x.ObjectXId).ExplicitKey()
    .For(x => x.NotWritable).NotWritable();

[NickCraver]

Initial thoughts: IMO this is very heavy handed attempting to be fluent where isn't not needed (nor a common thing in our patterns currently). It seems to be this could be much simpler, simply registering the properties as keys via nameof() and we get the PropertyInfo, etc. - extending existing functionality.

The above assumes the feature is really needed, and I'm not sure this is the case - there may be other even simpler approaches.

[vantheshark]

The current code has private static dictionaries to cache PropertyInfo object by types.
Whatever approaches, there should be a way to access those private caches.
Making them public will make everything ugly IMO. Current attributes (Key, Explicit, Write, etc) are resolved via PropertyInfo.GetCustomAttributes().
To add different way of building the type map, it will need to have a Attribute provider or something because GetCustomAttributes() is static and there is no way to override it.

I'm not sure how to cache the custom PropertyInfo using nameof() without changing CRUID sync/async methods in SqlMapperExtensions.cs. I came to this as I want to use "async" InsertAsync() method while I cannot put attributes to my model classes.

Anyways, It's quite fun to play with dnx the first time ;)

[NickCraver]

Closing this out to cleanup - the notes above stand. I don't disagree with the general premise of pluggability here, but the API compared to the rest of dapper is very foreign, e.g. nothing looks or feels like this in any fundamental way. I don't want to dismiss the idea of making this extensible, only the implementation approach as it stands. We want to make the mappings pluggable in v2. I'll be adding it to the project notes there (a link will appear below shortly).