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.
Could you also measure the big JS applications such as Octane (https://developers.google.com/octane/)?

For the generated optimized code, I did not see you turn on the FLAG_hydrogen_track_positions flag. We should turn on this flag in order to achieve the same result with the current approach, right?

I am thinking this pull request is less general than the current approach. The current approach (event listener) separates the VM implementation and profiler implementation. The Chromium CPU profiler is also using this approach and maintains the code map instead of iterating the relocation table.