This enables callback-style programming where the JavaScript environment can call back into the Wasm environment using a function pointer received from the module.
Currently Emscripten post-processes the Wasm file to add stub functions to enable this. Alon was concerned that when the function table was exported, performance might suffer? I'll do some quick tests to confirm this.
Edit: I've now done some benchmarking. Whether the table is exported or not has no observable effect on performance that I could find (results: https://github.com/kripken/emscripten/issues/6155)
Whether you use the JS Table object to jump into Wasm, rather than using a named dynCall stub, may have a performance effect, but exporting the table doesn't force that decision in any way.
Config members are named after their command line options, so this member should be "ImportTable" or "ExportTable" and have a boolean value.