Heap refactoring. 

This pull request did some clean up of Heap. It contains the following changes:
  1. Make ``Heap.Heaplist`` be private. Heap's internal implementation (implemented in linear list or other data structure) should be invisible to user and it is also not safe to allow user directly index into ``Heap.Heaplist``.  Besides, as all data eventually is stored in ``StackValue``, for a pointer it doesn't make sense to ask user to get raw integer value from ``StackValue`` and use it to index into ``Heap.Heaplist``. In this pull request a new method ```Heap.GetHeapElement(StackValue pointer)``` is added to provide a centralized way to get ``HeapElement`` from ``Heap``.
  2. Move some functions in HeapUtils.cs and Runtimememory.cs to Heap. These functions are about creating some type of object: array, string, etc. It is heap's key job, shouldn't be done in util function. These functions ares:
    - ``StackValue AllocateString(string str)``
    - ``StackValue AllocateArray(StackValue[] values)``
    - ``StackValue AllocatePointer(int size)``
    - ``StackValue AllocatePointer(int size, Metadata metadata)``
  3. Remove some dead code in ``Heap``. 
  4. Remove unnecessary heap lock in the executive. Again, locking a heap is heap's job, so even a lock is necessary,  client side shouldn't explicitly lock it. The lock should be done internally. 

The cleanup is not finished yet. For example, in many places ``HeapElement.Stack[]`` is directly read and write. It is unsafe because not all data in ``HeapElement.Stack[]`` is valid data. Also, we need to think about if ``HeapElement`` should be invisible from user through adding new type like ``DSArray``, ``DSString`` and ``DSHeapObject`` to encapsulate the access to ``HeapElement``. These need further discussion andy may be addressed in other pull requests.

@lukechurch , @junmendoza , @sharadkjaiswal, @Benglin  could you please help to review the change? Thanks. 
I'm wondering why don't we do ```Clear``` for both?