[compiler] Optimize props spread for common cases

[josephsavona]

As part of the new inference model we updated to (correctly) treat destructuring spread as creating a new mutable object. This had the unfortunate side-effect of reducing precision on destructuring of props, though:

function Component({x, ...rest}) {
  const z = rest.z;
  identity(z);
  return <Stringify x={x} z={z} />;
}

Memoized as the following, where we don't realize that z is actually frozen:

function Component(t0) {
  const $ = _c(6);
  let x;
  let z;
  if ($[0] !== t0) {
    const { x: t1, ...rest } = t0;
    x = t1;
    z = rest.z;
    identity(z);
...

#34341 was our first thought of how to do this (thanks @poteto for exploring this idea!). But during review it became clear that it was a bit more complicated than I had thought. So this PR explores a more conservative alternative. The idea is:

• Track known sources of frozen values: component props, hook params, and hook return values.
• Find all object spreads where the rvalue is a known frozen value.
• Look at how such objects are used, and if they are only used to access properties (PropertyLoad/Destructure), pass to hooks, or pass to jsx then we can be very confident the object is not mutated. We consider any such objects to be frozen, even though technically spread creates a new object.

See new fixtures for more examples.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• -> [compiler] Optimize props spread for common cases #34900
• [compiler] More fbt compatibility #34887