Refactor loader

[jnordberg]

Fixes #410

Also allows default trace and abort functions to use more efficient getString when available. Tests passing and should be backwards compatible.

[dcodeIO]

While looking at this I figured that it totally makes sense to move the accessors to the memory instance, as it also avoids naming collisions with actual exports naturally. Might be worth to consider dropping backwards compatibility and update the documentation to the new semantics. Wdyt?

[dcodeIO]

Though, I believe that I had an issue once where it wasn't possible to extend a WebAssembly.Memory with new properties in some VM. Possible that my memory on this isn't correct or that this has been fixed already or something. Unsure.

[jnordberg]

Yeah sure, sounds good. Might make sense to create a api compatible wrapper object for the memory instance instead of extending it to avoid any troubles.

[jnordberg]

Ported to TypeScript and extracted the helpers out from the module namespace into memory and table wrappers that does not modify the underlying WebAssembly.Memory and WebAssembly.Table instances. Should work in all VMs

[willemneal]

This looks great! I had solved the issue by adding getStringImpl as an export, but this is a lot cleaner.

However, another needed feature for the loader has to do with running multithreaded code. I've been working on a library that implements the web worker API and one important aspect is that each instantiation of a module will copy the data section into memory, which can overwrite shared memory. Thus you need to first create a module with just the data to be instantiated and then use the exported memory for each of the subsequent modules. I had first solved this by hacking at the compile itself to not emit a data section. However, I think the best way to approach this is to use the parser to split a data section and module at load time. This is something that I'm also close to finishing, but am unsure where this all should take place. Your class abstraction might be the key; perhaps my threading library can just extend it to add this feature.

[dcodeIO]

Looking good so far! Code style should use semicolons, though, because that's essentially what's used everywhere else.

With no immediately useable index.js it might also make sense to separate the project into multiple subprojects first, like one for the compiler, one for the loader, one for the CLI and one for each example or something. Could use lerna or similar for that. Ideas on best practices in this regard?

[jnordberg]

Semicolons added

I haven't used lerna before but seen it used in some projects and I like the structure. I think it could be a good option.

[dcodeIO]

Or let's just add a new dist/assemblyscript-loader.js, ideally together with a .d.ts, that should do for now. Also, please add yourself to NOTICE before I merge :)

[dcodeIO]

Sorry, took me a while to get to this, mostly because I'd like to actually play around with it a bit on top of master. Thanks! :)

[dcodeIO]

Hrm, actually, when I opened the loader source locally it instantly went all red due to code style issues (tslint vscode ext), like indentation, missing return types, single quoted strings, redundant public keywords. Really thought I had looked through this more thoroughly before, sorry. Going to revert for now. Let me know if you'd like to tackle those issues.