Use BigInt for i64 FFI and remove existing i64/f64 casting tricks

[TerrorJack]

Is your feature request related to a problem? Please describe. WebAssembly MVP prohibits i64 as an FFI argument/result type, and we had to work around the restriction. Previously, the major way is performing i64/f64 casting at the wasm/js boundary, which bears the risk of undetected precision loss. There has been a WebAssembly proposal for enabling wasm i64 as an FFI type using JavaScript BigInt, but we held off using that since it wasn't enabled in major browsers.

This is now no longer the case:

• The proposal proceeded into WebAssembly main spec
• V8 announced in a recent release that the feature has been shipped
• According to Wasm Feature Detect, Firefox nightly and Chrome dev supported this feature

It is safe to assume that in the near future, this feature will be available on major platforms, and we can take advantage of it to remove existing i64/f64 casting on the FFI boundary.

Describe the solution you'd like

• [ ] Enable the --experimental-wasm-bigint flag for node since this isn't on by default on node yet
• [ ] Refactor the JavaScript runtime and the builtin functions, use i64 for imports/exports and remove all existing casting logic
• [ ] Refactor the JSFFI code generator, so that the JSFFI imports/exports use i64 in the wasm import/export type signature, and do not perform casting in the wrapper function
• [ ] Mention in documentation about the new WebAssembly feature we use

Describe alternatives you've considered The main alternative approach is preserving a linear memory region as the "value stack" for passing arguments/results across FFI boundary. It's the mechanism used by wasm-bindgen in rust. We may implement this in the future, but it takes a lot more work, thus we should emphasize on getting rid of i64/f64 casting for now to increase runtime robustness.