Throw exception at runtime if TestAdapter and TestFramework versions are mismatched

[Youssef1313]

I think it's generally a good idea to enforce the same TestAdapter and TestFramework versions. When there is a mismatch, the exception should include the two versions that were used.

While it can be seen as a breaking change, I wouldn't view it as such. We already often introduce APIs in MSTest.TestFramework and access them in MSTest.TestAdapter. This often already failed in the past when users updated TestAdapter but didn't update TestFramework.

[Evangelink]

We could also do something with targets and emit a warning (like for netstandard) that could be suppressed by users while waiting for a hard break.

[Youssef1313]

I wanted to explicitly make the version check at run-time so we are sure what's being loaded at run-time is correct.

Today, due to the same as explained in #5579, if we have the following setup:

1. Test helper library that uses MSTest.TestAdapter and MSTest.TestFramework version X (both versions aligned - putting aside that MSTest.TestAdapter shouldn't be referenced in this scenario, and let's say this is not using .NET Standard, so we don't warn today)
2. Test app using MTP and referencing the test helper library project, and it references MSTest.TestAdapter and MSTest.TestFramework version Y (both versions aligned, but different than from the library).

Then I think we will be hitting the same issue again and end up with adapter dll version X and TestFramework version Y.

With MSBuild, we will see the package versions aligned and not warn. But doing it at run time is going to be more reliable. If we need to allow suppressing it via MSBuild, I think something similar to what we do in vstest here may work well:

https://github.com/microsoft/vstest/blob/e894393f92f748898e4e1ef7608892cb16e00163/src/package/Microsoft.TestPlatform.TestHost/Microsoft.TestPlatform.TestHost.targets#L8-L11

https://github.com/microsoft/vstest/blob/e894393f92f748898e4e1ef7608892cb16e00163/src/testhost.x86/DefaultEngineInvoker.cs#L63-L67