[scripts] Update name of experimental Wasm V8 flags

[Liedtke]

These flags got renamed in https://crrev.com/c/8426472.

Note that this is just the code change, I don't know if there is any pipeline in place to automatically update the ClusterFuzz fuzzer.

[stevenfontanella]

@Liedtke can you run fuzz_opt.py as a sanity check?

Also I guess this would break the fuzzer with earlier versions of V8 that don't have the renamed flags. Is that fine @kripken? I get the impression that we don't care that much about backward compatibility with earlier versions of V8 for fuzzing.

[kripken]

Yes, we don't care about older V8 - we just expect people to update their V8.

[stevenfontanella]

LGTM if scripts/fuzz_opt.py runs successfully for a few iterations.

[Liedtke]

LGTM if scripts/fuzz_opt.py runs successfully for a few iterations.

It reached 4000 iterations, I mean those flags don't really do anything that could break the fuzzing loop, so I'd not expect it to be possible to fail because of this. We don't get any unknown flags warnings in the output.

It did fail afterwards because it ran into a DCHECK which is tracked by https://crbug.com/563427048. It's super easy to reach, so a lot of fuzzers run into it and it should hopefully stop when my second fix landed in V8. (This fixed it for caught exceptions but there was a second one for a missing exact on the Turboshaft type annotations for struct.new for a descriptor going to be fixed here.)
The custom descriptors part now is behind the flag without the experimental in the flag (though --wasm-staging is also enough, so this wouldn't really be needed), this is really just ensuring that we set the right flags that we'd like to fuzz.

[Liedtke]

[...] and it should hopefully stop when my second fix landed in V8.

This isn't the case as I already have this fix locally and besides the struct.new, there seems to be the same issue with struct.new_desc.
This DCHECK keeps on giving but this is unrelated to this binaryen PR (and it's just about small imperfections, not observable behavior differences in production.)

[Liedtke]

BTW I don't know why the emscripten run failed and didn't investigate:

em++: error: unexpected binaryen version: 133 (expected 132) [-Wversion-check] [-Werror]

[stevenfontanella]

I've seen it happen in other cases and I believe it's due to the recent version bump #9131. I'll rerun it for now, but it should be fine to ignore too since it's unrelated (cc @kripken if you have anything to add).