Fixed resolve type bug due to splitting out to different assemblies

[alxwest]

Calling ResolveReaderType in ContentTypeReaderManager would return null due to the resolvedReaderTypeName pointing to the wrong assembly.

[nkast]

I see that this is to resolve XNBs created by the MonoGame content builder.

• MonoGame and KNI runtime is compatible with old XNA XNBs, by mapping XNA types from [TypeName, Microsoft.Xna.Framework.*] to the internal types.

• MonoGame and KNI pipeline generate XNBs compatible with XNA by writing a fake AssemblyQualifiedName that resembles that of XNA [TypeName, Microsoft.Xna.Framework.*]. However MonoGame doesn't always stick to that and some types are written as [TypeName, Monogame.Framework]. Those types were resolved 'as-is' from Monogame.Framework.dll by the runtime.

Since all readers are now moved out of Monogame.Framework.dll, MG generated XNBs no longer work.

So..., this isn't an issue as long as you build content via the KNI content builder (or XNA). Also, if MonoGame were to fix the XNA backward compatibility for all stock-types then things would just work between the two libraries through the XNA mappings.

For what reason we should actively maintain compatibility with MonoGame's content assets?

[nkast]

FNA runtime also resolve XNA types, and apparently MonoGame -> FNA as well. That's is no surprise as FNA doesn't have it's own content builder and people have to use MonoGame to build assets.

https://github.com/FNA-XNA/FNA/blob/master/src/Content/ContentTypeReaderManager.cs#L346-L373

[nkast]

Ok, there are some benefits from this, to let people gradually port their games, building projects on linux which KNI doesn't support, and fixing issues by comparing differences between assets.

On the down side, it will hold us back from taking actions to address those issues.

I might write a warning on the console, because that is not a permanent solution.