Building an object stopped re-allocating its keys

Building an object is one of the most common things real code does - turning rows of data into records, options bags, event payloads - and every field of every object had been allocating its key string from scratch, over and over, in the hottest loops. Object keys are now interned once and shared, so building an object in a hot loop copies a reference to the key instead of allocating a fresh string for it. On a wide object of seven fields that is about a third faster; on a narrow two-field one about an eighth. The compiled fast path builds the object directly from the shared keys and is kept out of the compiler's hot dispatch loop, so it does not slow the arithmetic sharing that loop - a trap caught only because an unrelated nested-loop benchmark regressed until the object build was moved out of line. The change is proven equal to the interpreter by the differential fuzzer and the whole engine gate holds at 6375 of 6375. This release also fills in the Performance resource-timing buffer controls - clearResourceTimings, setResourceTimingBufferSize and a toJSON on performance - lifting the Web API surface to 496 of 577.