Separate DynamoCore into DynamoCore and DynamoCoreUI (DO NOT MERGE)

### The problem

Because Dynamo's Views, ViewModels, and Models all live in the same assembly, it's difficult to enforce separation of application layers in DynamoCore.  This pull request initiates an effort to separate the two into separate assemblies: DynamoCore and DynamoCoreUI.  

@Steell initially proposed this project - so here's a start for him.  :)

### The philosophy of the fix

*Models live in DynamoCore. ViewModels and Views live in DynamoCoreUI*

It's as simple as that.  DynamoCoreUI really represents the "WPF version" of Dynamo.  To initialize a "headless" Dynamo, you should only need symbols defined in DynamoCore.  

### Work completed

The "KillDynSettings" project did a lot of the grunt work to make this possible.

In this PR, I created the DynamoCoreUI project and moved all of the ViewModels and Views into this project.  I moved all `IWpfNode`'s into DynamoCoreUI, as well.  

I fixed some mistakes in the design of `NodeCollapser`, `PackageDownloadHandle`, `PackageSearchElement` - removing any direct references to the ViewModel layer.

### Further work

Presently there are 6 compiler errors in DynamoCore.  

It would be very helpful to have @Steell to complete this work.  Namely, the `DSVarArgFunction` class implements `IWpfNode`.  Unlike most `NodeModel`s, the `DSVarArgFunction` is referred to throughout `DynamoCore` as it has a unique constructor. This compile time dependency should be removed.  There's various ways to do this, but @Steell might have a strong opinion as this is his part of the code.  

Other than that and a few straggling references to `DynamoViewModel` in `Utilities` which could be removed by introducing some new events on DynamoModel, DynamoCore is compilable!  

We'll then need to:

1) make sure all existing projects are updated to reflect this change (i.e. tests)
2) remove all possible WPF deps to DynamoCore
3) move those references to DynamoCoreUI

### Reviewers 

@Benglin, @lukechurch, @ikeough, @Steell

Hmm... I'm seeing various things changed to ```public``` just so it is accessible, making me think twice about using assembly wide attribute ```InternalsVisibleTo```, not a must change of course, just for your considerations.