wasm-split fuzzing and reusing an existing Table

I seem to recall we discussed using a new Table in wasm-split, when reference types is set? Atm it looks like we reuse the table if one exists:

https://github.com/WebAssembly/binaryen/blob/28e849b91fab4fb697c27206b7d6f2c090e3519c/src/ir/module-splitting.cpp#L186-L191

The fuzzer errored on this, with exports like these:

 (func $0
 )
 (func $1
  (table.set $0
   (i32.const 1)
   (ref.null nofunc)
  )
  (unreachable)
 )
 (func $2
 )

After splitting these three out, we end up with call_indirects in all three in the primary module. The secondary module's elem writes the proper function pointers, but when we call $1 we trample some of that data, leading to the third export trapping. That is, it is unsafe to use the table for normal stuff and also wasm-split stuff, without the two being aware of each other.

cc @tlively @aheejin

Read src/ir/module-splitting.cpp at lines 186-191 and reproduce the reported fuzzer case with the shown wat. Trace how the existing table, call_indirects, and secondary-module element writes interact; done means ordinary table.set operations no longer overwrite wasm-split function pointers and the third export does not trap.