Merge pull request #2751 from akoeplinger/fix-msbuild-remapping

Merge pull request #2751 from akoeplinger/fix-msbuild-remapping

Fix msbuild remapping

First commit:
```
Revert "Do not remap framework assembly if it's version is higher than the runtime version"

It would cause issues on mobile, cause the runtime version is 2.0.5.0 there and loading
e.g. System.dll v4.0 would no longer be mapped to that version anymore after this change.
```
---
Second commit:
```
[runtime] Stop remapping higher versions of
 Microsoft.Build.Framework/Engine and remap Microsoft.Build.Utilities/Tasks
 (.v3.5)

The previous remapping was added in 725ed3f82400b1466ca17e99b85adcbde54238ca, but it didn't actually
fix the bug in https://bugzilla.xamarin.com/show_bug.cgi?id=32561.

The underlying cause of the bug is that in Mono 4.0 we removed the 2.0/3.5 profiles.
This meant that Microsoft.Build.Utilities.dll and Microsoft.Build.Utilities.v3.5.dll weren't installed
in the GAC anymore, because MSBuild 4.0 uses Microsoft.Build.Utilities.v4.0.dll, so the app failed
to load the 2.0 version of the assembly. The same applies for the .Tasks variants.

We remap earlier versions of the Microsoft.Build.Utilities/Tasks assemblies to the v4.0 version.
I've introduced another item in the AssemblyVersionMap struct which allows remapping to target a different
assembly name, because MSBuild made the questionable decision to put the version number in the assembly name.
While strictly speaking this is not what .NET is doing (it just fails there if .NET 2.0 isn't installed)
on Mono there's no way to install those older profiles anymore, so we remap them to v4.0 to keep apps working.

Newer versions of Microsoft.Build.Framework/Engine (like 12.0, 14.0) however have the same name, so we need to be
more careful here and only do a remapping to the 4.0 version if it's an earlier version (e.g. 2.0 -> 4.0).
This avoids issues with accidentally remapping 14.0 -> 4.0.

I tested the app from the bug report and it now works fine.
```