Redesign API structure/Extension loading

[ChrisMaddock]

In the v3 stream, there's been a long standing issue with API versioning that I think is best fixed with a breaking change as part of v4. Issue reference at #826.

Here's the changes I propose to fix this:

• We split the nunit.engine.api.dll assembly into smaller components.
• nunit.engine.api.dll becomes dedicated solely to the API's required by runners to access and utilise the engine. We start to increment the version of this assembly with every new version of the engine.
• We create an API assembly specific to each extension interface, versioned at 1.0, and only incremented when breaking changes to an extension interface need to be made. (Hopefully not until v5.0 - however this structure would allow us to make these changes causing minimum disruption if required.)
• There may be a need for a general extension api assembly to contain functionality shared by all known extension interfaces, also versioned as 1.0. I'm hoping we can architect that out, and avoid the need for it.
• Extensions should start to be packaged with the version of the API assemblies that the reference, rather than relying on the engine to be packaged with all versions.

[CharliePoole]

Nice idea. I'll add this to my pluggable agent experimentation.

[ChrisMaddock]

Plans to take this further now up for discussion in #948