Basic implementation of mark and sweep GC and code clean up -- part 1

This pull request implements a basic mark-and-sweep garbage collection. It is controlled by compilation flag ``GC_MARK_AND_SWEEP``. The garbage collection strategy by default is using reference counting, which is controlled by compilation flag ``GC_REFERENCE_COUNT`` as well. 

For mark-and-sweep GC, the major logic is  implemented in ``Heap.GCMarkAndSweep()``.

But most change in this pull request is code cleans up for ``RuntimeMemory``:

  * Implement ``RuntimeMemory.CurrentStackFrame`` and add properties, for example, ``ThisPtr``, ``ClassScope`` and so on to ``StackFrame``, so that we don't need to write error-prone and horrible code like 

```
ci = (int)core.Rmem.GetAtRelative(core.Rmem.GetStackIndex(ProtoCore.DSASM.StackFrame.kStackFrameIndex)))
```
  
  * Delete some duplicate functions in ``RuntimeMemory``. For example, ``RuntimeMemory.Pop(int size)``, ``RuntimeMemory.PopFrame(int size)`` and ``RuntimeMemory.PopGlobFrame(int size)``, these three are doing the exact same thing, and get randomly used in the core. 

  * Remove unnecessary properties in ``RuntimeMemory``, for example, ``ClassTable`` (!!), ``Executable``. 

  * Add test fixture ``TestHeapMarkSweep``.

  * Other clean up work.

The existing problem of mark-and-sweep GC: *currently gc root objects are not correct*. This issue will be addressed in the following pull request. This pull request shouldn't have any impact on the existing garbage collection strategy. 

@junmendoza , @lukechurch , please take a look. 
This is fine to replace with GetSymbolValue that takes a symbol. 
However, Do you still find instances of GetStackData being used? Because GetStackData  was intended to get the stackvalue within the current stackframe regardless of the arguments. The data could have been a symbol or any of the fixed stack frame data (this pts, function index etc)