Previously we used the start address of the AbstractCode object. This
doesn't make sense for off-heap builtins, where the code isn't contained
in the object itself. It also hides other potential problems - sometimes
the sample.pc is inside the AbstractCode object header - this is
never valid.

There were a few changes necessary to make this happen:
  - Change the interface of CodeMoveEvent. Now 'to' and 'from' are both
    AbstractCode objects, which is nice because many users were taking
    'to' and adding the header offset to it to try and find the
    instruction start address. This isn't valid for off-heap builtins.
  - Fix a bug in CodeMap::MoveCode where we didn't update the CodeEntry
    object to reflect the new instruction_start.
  - Rename the 'start' field in all of the CodeEventRecord sub-classes
    to make it clear that this is the address of the first instruction.
  - Fix the confusion in RecordTickSample between 'tos' and 'pc' which
    caused pc_offset to be calculated incorrectly.

Bug: v8:7983
Change-Id: I3e9dddf74e4b2e96a5f031d216ef7008d6f184d1
Reviewed-on: https://chromium-review.googlesource.com/1148457
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54749}