Support generic user implemented mappings

Add support for user implemented generic mapping methods:

class Optional<T> where T : notnull { public T? Value; }
class User { string Id; }
class UserDto { string Id; }
class Document { Optional<User> ModifiedBy; }
class DocumentDto { Optional<UserDto> ModifiedBy; }

[Mapper]
public partial class Mapper
{
    public partial DocumentDto MapDocument(Document source);
    
    private Optional<T> MapOptional<TTarget, TSource>(Optional<TSource> source)
    {
        return new Optional<TTarget> { Value = Map<TTarget>(source.Value) };
    }

    private partial T Map(object source);

    private partial UserDto MapUser(User source);
}

Mapperly should use the user implemented MapOptional method to map Document.ModifiedBy to DocumentDto.ModifiedBy. Depends on https://github.com/riok/mapperly/issues/357. Discussed in #444.

[latonz]

https://github.com/riok/mapperly/issues/421 occurred when Mapperly didn’t have any support for generic methods, but still tried to call them. If a generic method was implemented by a user, Mapperly handled the generic type as any other type. Therefore it did type checks with typeof(TGeneric) which won’t work outside the method itself, also methods with a generic target type were called like any other method, without explicit type arguments. But if the return type is a type argument, the c# compiler cannot infer the type. The fix to #421 was to just ignore them for now and open this issue to implement support. Example of how Mapperly would currently invoke generic user implemented methods if it has a generic return type:

// user implemented mapping method
TTarget Map<TSource, TTarget>(TSource source)
    where TSource : IMyInterface
    where TTarget : new(), IMyOtherInterface
  => new TTarget { MyValue = source.MyValue };

// would currently be called by Mapperly
var target = Map(source);

// instead of
var target = Map<MySource, MyTarget>(soruce);

To support this, as you figured out, Mapperly needs to implement generic mapping support during the mapping resolution in MappingCollection and UserMethodMappingExtractor.BuildUserImplementedMapping. Additionally the syntax generation needs to be aware of generics and whether they need to be specified explicitly. Probably a new GenericUserImplementedMethodMapping is needed or the existing UserImplementedMethodMapping could be adjusted. In the Build method of the generic mapping, the Invocation needs to be a GenericInvocation if type arguments need to be specified explicitly.

[latonz]

@Fube I think this works for methods where the source is the only generic type argument (would definitely need some cleanup 😄). If the target is (also) generic, not only the lookup side, but also the syntax generation side needs to be adjusted as explicit specification of the generic type arguments is required.