Combine nunit3 drivers and switch to new interface

[CharliePoole]

The NUnit3FrameworkDriver is still using the original framework API we created for NUnit3. Back in 2018, @rprouse created an improved API for use with the .NET Core targets but we have continued to use the older API for .NET Framework targets.

Until recently, we were supporting three different NUnit3 drivers. The removal of the .NET Standard driver, which has not been used for a while, brought us to two.

In this issue, I'm proposing to combine those two, NUnit3FrameworkDriver and NUnitNetCore31Driver into a single driver combining the code for both .NET Framework and .NET Core and allowing the driver to decide which API to use depending on the target runtime and NUnit framework version in use. This can give a number of benefits.

1. A cleaner API for NUnit 4 and newer builds of NUnit 3.
2. Simpler code in the driver factory
3. Fewer tests to maintain
4. In my opinion, code that makes it easier to understand the differences between the two APIs and how we use them.

Tasks

• Refactor the two drivers so they "line up" cleanly for comparison.
• Create an initial build of the new driver, using conditional code, which is functionally equivalent to what we have now, and switch over to using it for all targets.
• Switch dynamically to use the new API for NUnit versions that support it.
• Remove the two old drivers.

[CharliePoole]

The current state of PR #1597 is that we have a combined file but that I haven't yet been successful in getting the "new" API, which I am referring to as Api2018 to work under .NET Framework.

While I keep working on this, here's a more general question for the @nunit/engine-team...

What's the clearest, easiest to understand structure for the driver code, in your opinion?

1. Separate classes for ..NET Framework and .NET Core, as it was originally and after commit 1.
2. Combined class with scattered conditional statements. (commit 2)
3. Combined class with separate nested api implementation classes (commits 3 and 4)
4. Same as (3) but un-nest the implementation classes and put in separate files.

Personally, I liked (2) for readability, but I felt I needed the separated api classes in order to move ahead with using the 2018 api under .NET Framework. It's also potentially useful if the framework ever comes up with a third api.

[CharliePoole]

This issue has been resolved in version 4.0.0-beta.1

The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org