Graphutilities cleanup

This pull request removes static class GraphUtilities. 

Previously, ``GraphUtilities`` was used in many places: library services, code block node, some util classes, live runner and in test framework. Internally it has a static ``ProtoCore`` core to do parsing, compilation and library loading work. Although it has different clients, but all clients share a same static core, so It is a headache to properly manage the state of this static core. We have to frequently call ``GraphUtilities.Reset()`` to restore the static core to its previous state in case ``GraphUtilities`` was used in somewhere else and the core was changed. For example, in DynamoCoreTests, as library tests and other tests will finally use some static member functions in ``GraphUtilities`` to do parsing and compiling, some tests will fail for the second run. 

Following are the major changes for ``GraphUtilities``:
  * Some compilation related functions are moved to a static class CompilerUtils. Although this class is a static class as well, but all its static member functions require a core. They are:
    * ``bool PreCompileCodeBlock(Core core, ref ParseParam parseParams)``
    * ``ProtoCore.BuildStatus PreCompile(string code, Core core, CodeBlockNode codeBlock, out int blockId)``
    * ``bool TryLoadAssemblyInCore(Core core, string assemblyPath)``
  * Some parsing related functions are moved to ParserUtils, they don't dependent on core.
    * `` ProtoCore.AST.Node Parse(string code)``
  * Some are moved to ``GraphCompiler`` and ``GraphBuilder``, if they are not general enough. 
  * Some library loading related functions are moved to ``LibraryServices``.

As ``GraphUtilities`` is removed, ``LibraryServices`` is no longer a static class as well, and the parsing in code block node doesn't depend on the static core from ``GraphUtilities``. Instead, ``EngineController`` creates a core which will be used by ``LibraryServices`` and code block node. As ``EngineController`` will be re-created for new workspace, we don't need to worry about re-setting the core. Similarly, library tests now can run for multiple times without worry about state pollution. 

I've run ProtoTest to ensure no regression. 

@aparajit-pratap, @Benglin , @junmendoza , please review and comment. Thanks. 
Would you think this can be simplified as:

```cs
downloadPkg.LoadIntoDynamo(dynamoViewModel.Model);
```

And then internally ```LoadIntoDynamo``` becomes:

```cs
LoadIntoDynamo(DynamoModel dynamoModel)
{
    var loader = dynamoModel.Loader;
    var logger = dynamoModel.Logger;
    var libraryServices = dynamoModel.EngineController.LibraryServices;
}
```

Of course that depends on if ```LoadIntoDynamo``` should know about where and how to obtain ```Loader``` and ```Logger```, and how much of the *configurability* we want for it. From the way it looks, all callers are doing these exactly the same way.