RFC: Put unreachablility inside abort function

[MaxGraey]

Currently "assert" function and exceptions required one external abort function and one "unreachable" on wasm side.
But what if, instead of inserting unreachable on the wasm side after the abort call, we move the completion of the program to the host side?

Current approach:

function assert(cond: bool, msg: string | null = null): void {
   if (cond) {
     abort(__FILE, __LINE, __COLUMN, msg);
     unreachable();
   }
}

Proposed approach:

function assert(cond: bool, msg: string | null = null): void {
   if (cond) {
     abort(__FILE, __LINE, __COLUMN, msg);
   }
}

and on host side use something like this:

const imports = {
  env: {
    abort(file, line, column, msg) {
      throw new AbortError(`Abort at ${file}[${line}, ${column}]: ${__getString(msg)}`);
    }
  }
}

Pros:

• Reduce binary size
• Allows us to turn on recent TrapsNeverHappen mode which will remove much more dead code.

Cons:

• Breaking changes which especially sensitive for non-web environments.
• Now the processing of program termination delegate to the host's side. This can be both an advantage (e.g., user can just ignore the assert or specific assert and continue program working) and a disadvantage (non-deterministic termination depends from host to host decision). In general, this point is quite controversial.

Thoghts?

[dcodeIO]

My immediate thoughts are that we probably cannot trivially remove the use of unreachable, since we are generating it in many places, provide it as a built-in (quite a breaking change removing it), and there are use cases where trapping instead of calling an import can be desirable.

I would be OK with a separate intrinsic as Alon suggested I think, and separately also see a future where we largely switch to exception handling, of course. As for a Binaryen-level intrinsic, naming it abort would kinda match what we currently do, but I would be fine with any name.

[MaxGraey]

Well, separate intrinsic also makes sense, it is not such a breaking change