update param of BinaryenRefNull to take BinaryenHeapType

[chharvey]

According to the WASM spec, the (ref.null <ht>) instruction takes a heap type as an argument, not a reference type. This PR updates BinaryenRefNull to align with that.

The parameter is changed from a BinaryenType to a BinaryenHeapType and removes the nullable assertion. This puts the onus on the caller to make sure they are passing in a correct type.

This is a breaking change and would require callers to be more careful about their arguments, but it provides for a more spec-aligned and predictable API.

Problem Statement

As an example of a problem it solves: say you’re using GC and you define your own custom heap type (example in JS):

(type $NumberUnion (struct
	(field $tag   i8)
	(field $int   i64)
	(field $float f64)
))

const tb = new binaryen.TypeBuilder();
tb.setStructType(0, [
	{type: binaryen.i32, packedType: "i8"},
	{type: binaryen.i64, packedType: "notPacked"},
	{type: binaryen.f64, packedType: "notPacked"},
]);
const heaptypes = tb.buildAndDispose();
const ht_NumberUnion = heaptypes[0];

and then you want to create a null-ref expression (ref.null $NumberUnion) in your module code:

const mod = new binaryen.Module();
mod.ref.null(ht_NumberUnion); // error: `BinaryenRefNull` currently only accepts ref types

To fix, you have to create your own nullable ref type first:

mod.ref.null(binaryen.getTypeFromHeapType(ht_NumberUnion, true));

With this PR’s proposed change, you can now just call BinaryenRefNull passing in your heap type.

[chharvey]

This 'none' (BinaryenTypeNone()) refers to the type with stack effect [t*] -> []. It is not the WASM heap type none (BinaryenHeapTypeNone()), nor the WASM ref type (ref null none) (BinaryenTypeNullref()).

We should probably document this somewhere or change it to a less conflicting name like 'void'.