Port bb31db3a

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.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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