Add test case for invalid lambdas

This is the example we discussed in our design sync. ```javascript function Component(props) { const [x, setX] = useState({ value: "" }); const onChange = (e) => { // INVALID! should use copy-on-write and pass the new value x.value = e.target.value; setX(x); }; return <input value={x.value} onChange={onChange} />; } ``` Here `onChange` is a mutable lambda, and it should be invalid to pass a mutable lambda where a frozen value is expected. This is because unlike other value types, you cannot freeze a lambda — the only choice is to not call it at all. Note that there is a harder case to catch: ```js function Component(props) { const [x, setX] = useState({ value: "" }); const onChange = (e) => { // INVALID! should use copy-on-write and pass the new value x.value = e.target.value; setX(x); }; const x = constructAValueThatMaybeAliasesItsInput(onChange); return <input value={x.value} onChange={x.maybeGetTheLambdaBack()} />; } ``` This case demonstrates how mutable lambdas can be captured and then accessed later — the analysis to catch this case is more sophisticated bc it involves inferring that `x` aliases a mutable lambda. But we also can't be sure that `x` does alias the lambda, so disallowing this code could prevent a lot of valid code from compiling. My hypothesis is that we should start with at least validating the example at the top, while allowing the second case for now.