Create new nunit.extensibility and nunit.extensibility.api assemblies

[CharliePoole]

Fixes #1049

[CharliePoole]

@manfred-brands As I told you on slack, I'm hoping you'll continue to review these major structural changes I'm making. This is another wide-ranging one and I think it will take some time, but the reviews are really productive. If you're worn out for the moment, I'll ask for volunteers

[manfred-brands]

Overall looks good, except for two big issues:

1. Don't drop nullability. Not even for NUnit tests. The NUnit.Analyzer will fix most errors.
2. Come up with a better exception than Exception to throw.

[CharliePoole]

Thanks for reviewing. To your general comments...

1. You're right... I was experimenting with removing it for tests because I have the impression that it's more trouble than it is worth in tests. That's one thing I'd like to chat about with you, so as to reach a common understanding. However, I did talk with Terje about it and he also favors making tests nullable so that should be the goal.
2. I'm thinking that as well, I just failed to decide on a name.

[manfred-brands]

I have the impression that it's more trouble than it is worth in tests.

Why should unit test have a lower standard than the rest of the code?
The nunit.analyzers help a lot, suppressing warnings about uninitialised fields when these are set in Setup methods and when accessing nullable values after testing for Is.Not.Null.

[CharliePoole]

Sorry, but I don't think that not using nullability means "lower standard". We made an effort to keep high standards before it existed. It could mean that maintaining a higher standard becomes easier, which is why I'm working at it now. When it first came out, I didn't believe the hype and since then I've been mostly working alone.

You convinced me to try it, to learn about it. That means you'll see me trying to find out if it's good in various places or not. Be happy for me. :-)

NUnit.Analyzers: I didn't know it did that. That's probably why adding the Nullability.props import without adding the analyzer caused so much trouble. I think this stuff needs to be more centralized, perhaps in Directory.Build.props.

[CharliePoole]

@manfred-brands Waiting for you to re-review.

[manfred-brands]

One remaining question otherwise looks good.

[manfred-brands]

Commented out code. Does something need fixing?

[CharliePoole]

Because of changes in the API, extensions written for version 3 will need to be re-written, which is why almost all of them were already commented-out until I have a chance to look at them individually. For some reason I don't actually understand, the ResultWriter extension continued to work until this latest change. I decided to postpone it until the infrastructure changes are done.