XDK heap profiler collector
Extend CPU profiler with mapping ticks to source lines

This patch applies changes from https://codereview.chromium.org/682143003/ review.

The code introduces instruction_start attribute to CodeEntry class.
Therefore each code entry has at least one instruction mapped to a source location.
This patch also fixes fast/events/window-onerror-02.html chromium test as well as
following v8-crosswalk debug tests:

cctest/test-api/CallICFastApi_SimpleSignature_Miss2WithProfiler
cctest/test-api/CallICFastApi_SimpleSignature_TypeErrorWithProfiler
cctest/test-api/InterceptorCallICFastApi_SimpleSignature_Miss3WithProfiler
cctest/test-api/InterceptorCallICFastApi_SimpleSignature_TypeErrorWithProfiler
cctest/test-profile-generator/NoSamples
cctest/test-profile-generator/RecordTickSample
cctest/test-profile-generator/SampleIds
[Backport] Fix clang++ warnings on -Wtautological-constant-out-of-range-compare

BUG=v8:3730
LOG=N
R=dslomov@chromium.org

Review URL: https://codereview.chromium.org/750093003

Cr-Commit-Position: refs/heads/master@{#25579}
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.