More control over object creation

[BalassaMarton]

Use case: We need subtype mapping, but not based on objectclass. The two types have the same objectclass, but they are distinguished by organizational unit (ou).

Proposal:

1. Allow hooking into IObjectMapping.Create from IClassMap (or a new interface to avoid breaking changes).
2. Make the SearchResultEntry accessible for the IClassMap so that it can decide what type to instantiate based on arbitrary attributes.

Implementation notes: I understand that this would require breaking changes to the IClassMap interface, so my idea is to add a static type called something like MappingContext, and expose the current SearchResultEntry through an async local variable called Current. User code would look something like this:

SearchResultEntry entry = MappingContext.Current.Entry;
if (entry.DistinguishedName.Contains("ou=foo") return new Foo();
return new Bar();

[BalassaMarton]

To make it more robust, even a custom IResultTransformer could be provided by the IClassMap. But for that, classes like ResultTransformer need to be refactored and made public so that we don't end up with copy-pasta of property mapping and other generic code.

[madhatter22]

I like the idea of allowing you to determine how to construct the object. IClassMap should allow you to provide a Create implementation in the form of Func<SearchResultEntry, T>, but only IObjectMapping should be concerned with the use of the function. Create should also be changed to take SearchResultEntry as a parameter. It's already receiving object classes from the entry as parameters.

This is also an opportunity to simplify the subclass mapping. I should also be able to support the same functionality via attribute mapping of a static method on the class.