Separate assembly for NUnit extensibility

[CharliePoole]

This feature was first developed as "Engine Extensibility" so the implementation is embodied in an engine service. This makes it next to impossible to use extensibility in other places, like in the console runner, third party runners and even in our own agents.

I propose that we create a separate assembly... NUnit.Extensibility to contain most of the implementation... the existing engine service would simply use an API to access the implementation details.

As a subsquent improvement (but not part of this issue) we could implement the IFrameworkDriverFactory extension in nunit.core using the API directly, without need for full access to engine services.

I'm calling this an idea for now and asking for @nunit/engine-team discussion.

[CharliePoole]

@jnm2 @mikkelbu Any thoughts on this?

[CharliePoole]

I'm fleshing this out further and starting to work on it. Hoping that it will make enough sense to engender comments as I get more into the details!

Here's how I break this down stepwise...

Pre-4.0 Change:

• Split ExtensionService into two classes: the service itself and an implementation class #1120

Non-Breaking 4.0 Changes

• Make DriverService no longer a service #1122
• Remove services from nunit.engine.core assembly #934
• Actually create the new assembly (this issue)

Breaking 4.0 Change:

• Modify engine package to use the tools directory and have NUnit-Console load the engine as an extension using ExtensionManager.