Remove dynSettings and DynamoController from all of Dynamo

### The problem

The `dynSettings` class has for a long time represented a crutch in DynamoCore.  It provides static references to `DynamoModel` or `DynamoViewModel` (via `DynamoController`) from anywhere in the code.  It goes without saying that such a static data structure is bad idea, but here's a few:

* It enables devs to easily break the separation between business, application, and presentation layers.
* Makes it difficult to reason about what component knows about what - making debugging and testing more difficult.
* It's impossible to initialize more than one Dynamo in the same app domain.
* It's inconsistent with the rest of the MVVM based system.

DynamoController is indirectly responsible for most of these things.  There is no strong reason for it to exist in DynamoCore and it only serves to confuse the MVVM based architecture.  It is also removed.  

### The philosophy of the fix

#### Use composition to make access explicit

We should force developers to explicitly provide access to the data structures they need in their component.  If the component needs access to another data structure, they should explicitly provide access in the constructor.  By making the requirements of their component explicit at creation time, developers can enforce the principal of least knowledge.

```
var model = new Model();
var viewModel = new ViewModel(model);
var view = new View(viewModel);
```

Previously, because of dynSettings, most of Dynamo did not follow this pattern.  Namely, classes in the Model layer often invoked methods on the ViewModel layer.  

#### The right kind of communication

Objects at any level should only be able to hold a reference to objects at the same level or a lower level.  For example, any type at the Model layer can have access to other Model types, but never a ViewModel type.  

* Views communicate to ViewModels via command bindings.
* ViewModels/Models notify about changes to Views via events (observables).  
* ViewModels communicate to Models via method calls.
* Models send messages to ViewModels/Views via events.  
* Models communicate to other Models via method calls. 

These contracts are now enforced in all of DynamoCore.

We can think about ViewModels as Models, just with the additional logic necessary to support commands and bindings, which are necessary for WPF support (but do not force the ViewModel to be WPF specific).

### Other fixes
 
* Moved `PackageLoader` to `DynamoLoader`
* Added `NodeFactory` class to `WorkspaceModel`
* Moved `DynamoRunner`, `Logger`, `CustomNodeManager`, `SearchModel` to `DynamoModel`
* `AddConnector`, `AddNode`, `AddNote` methods moved to `WorkspaceModel`
* Moved `VisualizationManager`, `WatchHandler` to DynamoViewModel
* Separate `PackageManagerClient` into `PackageManagerClientViewModel` & `PackageManagerClient`
* Separate `SearchViewModel` into `SearchViewModel` & `SearchModel`
* Major cleanup of the `SearchElement` subtypes into Model types
* Separate LibraryServices.cs into multiple files
* Provide extensible `StartConfiguration` classes for `DynamoModel, RevitDynamoModel, DynamoViewModel`
* Major cleanup to `DynamoRevit`

### Reviewers 

@Benglin, @lukechurch, @ikeough, @Steell

This looks like the main idea of the Metroplex branch.  I'm all for it!  We definitely need a way of preventing anyone from manually mutating the node, note, collector collections in a WorkspaceModel.  

For now, I'm in danger of introducing too many changes to this PR, so I'm going to leave it out.  Let's touch base and make sure this goes in - it seems like I could branch and continue the work you did in Metroplex.