V8 CPU Profiler: source level support

The idea behind of this new solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously. When code generation is done you each code object has associated "relocation info". Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection), correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping. The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other)
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line. If a source line is found that hit counter is increased by one for this line 
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler. It's expected a minor patch in Blink to pack the source level info in JSON.
4. Add a test that checks how the samples are distributed through source lines. It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
I will check Octane.

Agree, the Chromium CPU profile maintains a code map. It is updated by CodeCreated, CodeMoved, and CodeDeleted events. What happens when you launch profiling after JS methods are compiled (e.g. run multiple profiling sessions for the same running process)? Before sampling is started, V8 emits CodeCreated events for the objects located on the heap. The code object's location can be changed multiple times between profiling sessions, and the CPU profiler does not care about code movement between profiling sessions, it just consumes them to build the code map before sampling is started. The question is how to maintain a map with source info between the profiling sessions. We can use use the reloc info that's already associated with each code object. So, on each "StartProfiling" call, the CPU profiler consumes a CodeCreated event for a certain JS function and can use its reloc info to get source level info. This way allows to avoid listening the events by the consumers all the time (including time when profiling is off).

About FLAG_hydrogen_track_positions flag, it's not used for Vtune afaik (please correct me) and the mapping to source line look quite precise. My experiments on an another app (SudokuSolver) showed the expected results. If we need to use this flag that it's common for debugger, Vtune, XDK and now Chromium CPU profiler. Anyway I tried it some time ago and encountered a crash. I did not investigate it because I thought that VTune, XDK does not require it.