Remove dynSettings and DynamoController from DynamoCore (DO NOT MERGE)

### 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

### Remaining work

*These changes still need to be applied to DynamoRevit and DynamoCoreTests.*  Currently, DynamoSandbox works solidly, but there is more testing to do.


### Submission

I will be breaking this pull request into separate, smaller pull requests.  This one is largely to clarify the overall goal and its status.


### Reviewers 

@Benglin, @lukechurch, @ikeough, @Steell

Just [the thing I've done](https://github.com/Benglin/Dynamo/compare/Metroplex) to encapsulate connectors/nodes/notes all within ```WorkspaceModel```! Which brings me to the point above, should ```WorkspaceModel``` resume all the responsibility of taking care of these collections and not exposing them to the outer world? If you look at my changes earlier, the ```WorkspaceModel``` only expose ```IEnumerable<NodeModel>``` instead of ```ObservableCollection``` so the external world cannot mess with these collections. What are your thoughts?