Avoid calling FindOrImport on ModelInspector

[ewoutkramer]

When we will have manually-created classmappings, these will not necessarily be represented using their own POCO anymore (e.g. custom resources, which are represented by DynamicResource) - this means that we will need to be consistent and lookup ClassMappings by their name (which can be a custom type), not their class (which will often by one of the Dynamic types).

This also means we should avoid FindOrImport, since not everything is based on a class. This then means we cannot "import" types as we find them, but rather we should have them all (lazily) present in the ModelInspector. This is already true for all the main POCOs (since we scan the assemblies), but it might not be true for Backbone types (I am not sure).

Also, this means we will no longer be able to discover satellite types via shared types, if we only load the shared types in the modelinspector initially. I think this is a good thing, since that only causes problems: we don't know the current FHIR version if we are reflecting on a shared type. But it does place the requirement on the user that all assemblies be loaded into the ModelInspector. Which I think is only fair.

[ewoutkramer]

There is more to this than meets the eye. We still need FindOrImport to create mappings for all the Code as they are encountered. And it is probably still used for the backbone types. That last one is easy to fix, but I am not too sure about the Code. Also, we're talking about to usecases here:

• We're reflecting on the ACTUAL types in POCO's. We should be able to call FindOrImport, instead of by name, as these types do never have a custom type name, so this won't conflict in the mappings
• We're trying to link from a property to a custom type. We have no facilities for doing this in PropertyMapping currently, but this should go via the lookup by name, not type (as the actual type, DynamicXXX, is ambiguous).