Javascript / WASM sample build script

[kwokcb]

Change

Add sample scripts to build or clean Javascript / WASM bindings on Linux or Mac.

Similar to the Windows but, with the only noticeable difference is the node version needs to be checked and updated as needed.

Assumes is being done from root of MaterialX with emsdk in a sibling folder. Input arguments can be used to set this w/o hand-editing the script.

[jstone-lucasfilm]

Thanks for this contribution, @kwokcb! Bringing the sample build flow to Linux and macOS is a welcome step, and taking the emsdk and MaterialX locations as arguments is an improvement over the hand-edited paths in the Windows scripts.

One correctness issue that I'd consider important to address: emsdk_env.sh ignores its arguments, evaluating only emsdk construct_env for whatever SDK is already active. So the install 4.0.8 and activate 4.0.8 lines are no-ops on a fresh emsdk checkout, and since construct_env succeeds either way, the || exit 1 guards never fire. Following the Windows script and our CI, I'd suggest calling emsdk install and emsdk activate directly, then sourcing emsdk_env.sh.

Before we commit to a direction, though, I'd like to propose an alternative. Rather than maintaining parallel .bat and .sh versions of the same sequence, we could replace both with a single javascript/build_javascript.py. A few thoughts on why this might be a better approach:

• Python is already a prerequisite here, since the emsdk launcher is itself a Python program, so this adds no new dependency.
• The existing .bat scripts and the new .sh scripts have already diverged on working directory, argument handling, and Node handling, and a single implementation would keep them aligned going forward.
• The JavaScript job in main.yml could invoke the script directly, making it the tested source of truth for the emsdk and Node pins, which today live separately in CI, the README, and each sample script.

The script could do exactly what the current scripts do and no more, printing each command as it runs, with a --clean flag in place of the separate clean script.

Does that sound like a reasonable path forward?