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.  


### 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 communicate to Views via events (largely observables).  

ViewModels communicate to Models via method calls.  Models send messages to ViewModels via events.  Models communicate to other Models via method calls.  


### Other fixes
  
* Added NodeFactory class to WorkspaceModel
* Moved DynamoRunner 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


### Remaining work

These changes still need to be moved to DynamoRevit.  Currently, DynamoSandbox works solidly, but there is more testing to do.