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. 
Judging from the number of times derive test classes do these sequence of things, it may represent maintenance issue in the long run. We should refactor them into a single ```protected InitializeLibraryServices``` method in the base class ```DSEvaluationViewModelUnitTest```, and then just call it from these derived test classes.