[SIMD.js] Implement SIMD128 data load and store APIs

It allows developers to load or store 1, 2, 3, and 4 elements of SIMD128
data from or to variable typed arrays.

The APIs inlucde:
SIMD.float32x4.load
SIMD.float32x4.loadX
SIMD.float32x4.loadXY
SIMD.float32x4.loadXYZ
SIMD.float32x4.store
SIMD.float32x4.storeX
SIMD.float32x4.storeXY
SIMD.float32x4.storeXYZ
SIMD.float64x2.load
SIMD.float64x2.loadX
SIMD.float64x2.store
SIMD.float64x2.storeX
SIMD.int32x4.load
SIMD.int32x4.loadX
SIMD.int32x4.loadXY
SIMD.int32x4.loadXYZ
SIMD.int32x4.store
SIMD.int32x4.storeX
SIMD.int32x4.storeXY
SIMD.int32x4.storeXYZ

This commit only optimizes accessing float32x4 in Float32Array and Int8Array,
accessing int32x4 in Int32Array and Int8Array as well as accessing float64x2
in Float64Array and Int8Array.

TODO=optimize for x64
TEST=mjsunit/simd/loadstore
BUG=XWALK-2865
Merge pull request #63 from huningxin/m39-load-store-pr

[SIMD.js] Implement SIMD128 data load and store APIs
XDK HeapProfiler bug fixes: object's types

determination and compilation on Windows

Details of the bug fix:
ClassNames::GetConstructorName returned before only the types for JSObject,
but there are a lot of objects, which are created for v8 purposes and which
exist in heap. User need to understand that these objects exist even if he
cannot affect this directly. I have added the v8 service types determination
as well added the detection of cases when type of the sevice object might be
defined only after analysis of the parent's object. For example the
(object properties) type might be determined only after analysing of the
parent and check follow conditions: 1. parent is a JSObject 2. the child object
is refered by the parent->properties().

The creation sequence of such dependent object are different and sometimes
children objects are created first, sometimes parents are created first.
To determine the type name correctly we need to make sure that the whole
object is created and start to resolve types only after this.
For making sure that objects are created we have added cyclic buffer
XDKAllocationTracker::latest_allocations_. It is filled until trashold, and
when trashold is achieved we start to pop old objects and resolve them. One pop
for one new allocated object.

There is some gap of objects == trashold which are not resolved, and we decided
to ignore this unresolved tail.