Fixes #1504 Part of #488

This fix adds a new method to the API for ExtensionManager to be used by ExtensionService.

The API already included ExtensionManager.FindExtensions(string initialDirectory). That method examines .addins files in the directory and uses each entry as a hint about where to find candidate assemblies in which extensions are sought. That method continues to exist and work as it has in the past. It will be used in a future enhancement to examine additional directories provided by the user.

This issue adds a new method, ExtensionManager.FindExtensions(string initialDirectory, string[] patterns). An internal algorithm (see below) uses initialDirectory as a starting point and searches for assemblies matching one of the patterns provided.

ExtensionService is also changed. In it's startup, it previously used the first method to locate extensions, but now it uses the new method, providing alternate filter patterns depending on whether it is looking for NuGet or Chocolatey extensions. It detects chocolatey by looking for the required file VERIFICATION.txt in the directory where the engine is installed.

THE ALGORITHM

The algorithm is internal, in the sense that the caller has no control over it except for providing the filters to be matched. ExtensionManager decides where to look for those matches. The current filters are the same as those previously used in our distributed .addins files but without the leading sequences of ../. Those addins files are now removed.

The current algorithm, which could be enhanced in the future, operates as follows...

1 Start in the provided initial directory's grandparent, two levels up.
2. Apply each pattern within that directory, recording the assemblies found as we have always done.
3. Move to the parent of the directory we just did and repeat at step 2 until the parent returns as null.

By continuously looking at parent directories, it turns out that we can find our way out of a standalone executable and locate installed extensions, which may be eight to ten levels up. In the current issue, I added one test to the netcore runner using an extension and it works. In issue #1505 I'll complete that work, making all extensions work.

In future, we could look for matches in additional places, e.g. in an addins directory in the initial directory. I decided to stick with the basics needed to get our own extensions working. The work on issue #488 will probably tell us if we need to do more here and will also bring the original FindExtensions method back into use to support additional root directories for locating extensions.

I added a few names of reviewers but I'm no longer familiar with who works on what. I would welcome reviews from any @nunit team members as well as users of the engine.