Support for custom reference importers in member cloner

[Washi1337]

Summary:
The reference importer (and by extensions the member cloner) performs a deep copy for all metadata members. For type references, this also means it clones the assembly reference it originates from. This can be a problem when we try to import a type that is targeting a different version of .NET than the assembly it is imported into is targeting (e.g. importing from a .NET framework to a .NET Core assembly). The proposal is to add support for automatically fixing up these kinds references to the appropriate .NET assembly reference.

Complications:
For different versions of the same library, this should be doable. But e.g. for .NET Framework to .NET Core, how do we find the assemblies that define the types that need to be fixed up?

[Washi1337]

Making up for differences within .NET versions is probably not going to be possible to do generically. We should probably change this issue to allow for custom ReferenceImporters in the MemberCloner instead, and let the end-user do the fixups.

[ds5678]

Support for custom ReferenceImporters in the MemberCloner is important to me, and I'm willing to work on it. How do you want this implemented?

[Washi1337]

Ideally, the MemberCloner could be initialized using a ReferenceImporter object, or perhaps even extract an IReferenceImporter to allow for even more flexibility.

One problem I encountered when I was trying this initially, is that the CloneContextAwareReferenceImporter still needs to be used somehow, as it is used to create proper references to members that were included in the cloning procedure. This opens up for some interesting edge-cases when it comes to the recursive behavior of the current ReferenceImporter implementation.

I haven't had the time to think it through more, but I am open to suggestions!