port bb31db3a (r33741)

  original commit message:
  (RELAND: the problem before was a missing write barrier for adding the code
  entry to the new closure. It's been addressed with a new macro instruction
  and test. The only change to this CL is the addition of two calls to
  __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

  We get less "pollution" of type feedback if we have one vector per native
  context, rather than one for the whole system. This CL moves the vector
  appropriately.

  We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
  vector actually lives in the first slot of the literals array (indeed there is
  great commonality between those arrays, they can be thought of as the same
  thing). So we make greater effort to ensure there is a valid literals array
  after compilation.

  This meant, for performance reasons, that we needed to extend
  FastNewClosureStub to support creating closures with literals. And ultimately,
  it drove us to move the optimized code map lookup out of FastNewClosureStub
  and into the compile lazy builtin.

  The heap change is trivial so I TBR Hannes for it...
  Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
  And Benedikt reviewed it as well.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33759}