Misc refactorings

[dcodeIO]

These are the first steps to implement closures as proposed in #798 (comment). Doesn't do anything new yet from a user's perspective, but levels the field for the actual implementation:

• Make function references managed usize (was plain u32)
• Skip every 16th function table entry
• Refcount function references if !(ref & AL_MASK)
• Inject closure context setup into call_indirects by checking for ref & AL_MASK. If a plain function table index, do an indirect call right away, otherwise unwrap the closure context first
• Refactor program/parser internals along asc to start with a new program right away, since native function references need to know whether usize is 32 or 64 bits now.
• Remove the call_indirect and call_direct builtins because these conflict with closure context setup.

Next steps:

• Detect and mark functions that are closures
• Allocate closure contexts on invocation
• Utilize closure contexts for closed-over locals

[dcodeIO]

Last commit wraps up the work done here in a way that closures are still not implemented, but the improvements made can be merged to master with no functional changes. Doing this because I expect a pre-pass PR to become messy, and doing all of that here would get us conflict hell.

In particular, this reverts

• Refcount function references if !(ref & AL_MASK)
• Inject closure context setup into call_indirects

but keeps usize function references and the new table alignment along with the general refactoring necessary to proceed.

[dcodeIO]

Now also reverts the table trick since fat pointers are another option.

[dcodeIO]

Last commit fixes respectively improves a few things:

• makeAutorelease lost some state as it used usize for a temp, which is never nullable since it is a basic type. Even had a FIXME there, so that's fixed now.
• Compiling string literals did not care about retains and autoreleases at all (which is logical because it's static data), but it turned out we can do better by compiling appropriate to context. If immediately retained, it does what we'd do for return values, and only otherwise doesn't care. Avoids unnecessary __retains when unifying branches like cond ? "a" : "b".
• There was some old code when unifying ternary branches that was commented out because it didn't work. This also tries harder now to compile appropriate to context by attempting to undo autoreleases if the result is immediately retained anyway.
• Added quite some comments to the autorelease helpers to explain the concept a bit better. Can be confusing :)

[dcodeIO]

Merging to get this out of the way so I can continue with something concrete :)

[MaxGraey]

I'm wondering why this happened? $1 not using inside this function at all

[dcodeIO]

Hmm, maybe that's retained and released in the function, with post-assemblyscript removing those, leaving the set behind since no further passes are run after that. Strange that it exists in the first place, though.