Per instance, cross platform library sandboxing support in wasm2c

[shravanrn]

@kripken Per our discussion here is the PR with all the wasm2c changes we needed to make to allow wasm2c to be used to sandbox libraries in the Firefox browser. (Fyi @deian) Briefly here are some of the more notable changes made)

• Windows/msvc support for runtime, codegen and builtins as well as support for a wider list of platforms/architectures/compilers including Android (arm architectures), Windows 32-bit etc.
• Support for growable indirect function call tables
• Support for library sandboxing apis --- wasm function type index lookup (so host can add new callbacks), make heaps aligned to 4gb for compatiblity with the RLBox sandboxing framework
• Allow multiple sandbox instances of the same library by moving global vars into a context structure that is passed to every function
• Migrated from emscripten to use of wasi-clang
• Upstream libc-wasi does not support windows, so I have written a minimal cross platform wasi support which includes just basic wasi function (just enough to get simple IO libraries running. Nothing complicated like networking or filesystem is supported)
• Removed use of per function call signal handler, setjmp/longjmp as this slows transitions
• Removed name mangling to simplify function lookup
• Remove stack depth counting as this adds unnecessary overhead
• A debugging aid built directly into wasm2c generated code that is similar to valgrind like shadow memory (significantly eases debugging of wasm)
• A wasm2c runner that can run full applications (code that has a main), when they are compiled via wasm2c to C and then to a shared library (.so/.dll)

I think this PR will likely be a starting point for discussion and we can discuss what we need to change/update so we can land this without issues

[kripken]

@sbc100

Just in terms of reviewing though it seem like there are two fairly large changes here being combined

Would it be practical to split those two, @shravanrn ? If so that sounds good to me. The work to split it out might be saved in being able to land one part first and not keep discussions on a single big PR (that waits on all items for landing).

But, if it's not practical to split out, I think it's ok for me to review as it is.

[shravanrn]

Sorry for the delay! Some last minute deadlines on my side. I'll be back to updating this PR and addressing the comments in a day or two

[shravanrn]

@kripken @sbc100 As you suggested, i think it may be easier to upstream this in batches. So, rather than landing this PR, @talg from our sandboxing team will be submitting PRs to upstream these changes in batches. This should allow us to more easily review and land things. Thanks @talg! :)

Let me know if you have any thoughts or concerns. Will close this PR if the above plan makes sense to you

[kripken]

Sounds like a good plan to me!

[sbc100]

@shravanrn is most of this stuff landed now? Are these still things that remain? i.e. should we close this now?

[shravanrn]

@sbc100 At least three of these points haven't been merged in

- A minimal cross platform wasi support which includes just basic wasi function (just enough to get simple IO libraries running. 
- A debugging aid built directly into wasm2c generated code that is similar to valgrind like shadow memory (significantly eases debugging of wasm)
- A wasm2c runner that can run full applications (code that has a main), when they are compiled via wasm2c to C and then to a shared library (.so/.dll)

But I think we can close this bug, we don't need to track these here. At some point, if I get around to re-implementing this, I'll open fresh issues/PRs

[sbc100]

OK, closing this for now.

Thanks for all the contributions @shravanrn!