[metadata] Fix hardcoded mono/2.0 path in assembly.c

[metadata] Fix hardcoded mono/2.0 path in assembly.c

The performance team discovered this on their bots using the Jenkins snapshot packages. Mono would fail to start with a message like:

```
The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `/opt/mono-2016.02.08+15.25.39/lib/mono/4.5/mscorlib.dll' directory.
```

The one odd thing is that they are using Mono installed in a path which is different from the prefix used during compilation.

It turns out that the runtime has a hardcoded check for lib/mono/2.0 in https://github.com/mono/mono/blob/7d5a7ea7ac324bb4ee63094ddcf8e20ae9ba4322/mono/metadata/assembly.c#L633-L637.
Since we recently stopped shipping 2.0 in the packages (we moved to 2.0-api for the reference assemblies) this directory wasn't there,
so the code in fallback() called into mono_config_get_assemblies_dir() which just returns the MONO_ASSEMBLIES preprocessor symbol.

That preprocessor symbol is defined to the value of --prefix during compilation, so Mono couldn't find corlib there as well since it's installed in another path which ultimately results in the above error message.

The fix is to change the hardcoded value to 4.5, which is what we established as the directory with the "latest" assemblies now.
Ideally we should find a way to stop hardcoding those paths in the runtime.

PS: I grepped through the runtime source to make sure we don't hardcode 2.0/3.5/4.0 elsewhere and only found one instance in a test.
I fixed it there as well, though the test looks suspicious since it hardcodes /usr ...