Add support for Unity Test Framework 2.x.

In 2.x the name of the test runner was changed from "Code-based tests runner" to just "tests-runner". This caused DestroyEverythingExceptTestRunner to fail since the runner could not be resolved.

This change will lazily try to find both versions, starting with v1, on the first access of UnitTestRunnerGameObjectName.

Thank you for sending a pull request! Please make sure you read the contribution guidelines

Pull request checklist

Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] No compiler errors or warnings

Pull request type

Please check the type of change your PR introduces: - [x] Bugfix - [ ] Feature - [ ] Code style update (formatting, renaming) - [ ] Refactoring (no functional changes, no api changes) - [ ] Build related changes - [ ] Documentation content changes - [ ] Other (please describe): ## Issue Number

Issue Number: N/A

Create or search an issue here: Extenject/Issues

What is the current behavior?

Test runner's name has been changed in Unity Test Framework 2.x, see https://github.com/modesttree/Zenject/issues/259

What is the new behavior?

The test runner name is now lazily evaluated by testing both versions. There are multiple ways of doing this, none is particularly clean. Ideally we would use a preprocessor define to determine the name at compile time, but I couldn't find one in the UTF test framework. Additionally, this tries to avoid destroying the test runner object when destroying scene objects.

Tested with Unity Test Framework:

1.1.31
1.1.33
2.0.1-pre.18

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

On which Unity version has this been tested?

[x] 2021.3.6f1
[ ] 2020.4 LTS
[ ] 2020.3
[ ] 2020.2
[ ] 2020.1
[ ] 2019.4 LTS
[ ] 2019.3
[ ] 2019.2
[ ] 2019.1
[ ] 2018.4 LTS

Scripting backend:

[x] Mono
[ ] IL2CPP

Note: Every pull request is tested on the Continuous Integration (CI) system to confirm that it works in Unity.

Ideally, the pull request will pass ("be green"). This means that all tests pass and there are no errors. However, it is not uncommon for the CI infrastructure itself to fail on specific platforms or for so-called "flaky" tests to fail ("be red"). Each CI failure must be manually inspected to determine the cause.

CI starts automatically when you open a pull request, but only Releasers/Collaborators can restart a CI run. If you believe CI is giving a false negative, ask a Releaser to restart the tests.

Mathijs-Bakker / Extenject