fix(compiler): Write universal exports on linked module

[ospencer]

In #2104, the write_universal_exports function was previously called after linking, but I forgot to reinstate it. This restores that behavior.

I deleted some tests because they were testing old behavior that was valid for the intermediate (object) wasm files but are no longer valid in the output of final wasm modules.

[spotandjake]

Mostly looks good just two small questions.

[spotandjake]

I was testing with this locally and I think we changed the behaviour of the start function.
The below program:

module Test

provide let _start = () => print("test")

when compiled with grain compile ./test.gr --use-start-section gives an error during compilation Fatal: Module::addFunction: _start already exists, oh actually interestingly I get that even if I omit the --use-start-section

We also get similar behaviour with provide let memory = () => 1 because of the memory section export.

[ospencer]

@spotandjake Good catch. I restored the old behavior. We should maybe consider a warning for reserved export names, but that's not for this PR.

[spotandjake]

I just tried this again the _start stuff is fixed but I found a new bug if you have a program like:
b.gr:

module B

provide let x = (y) => 1

a.gr

module A
from "./b.gr" include B
provide let x = B.x

we seem to hit a Not_found exception.

It might also make sense to add regression tests for both the _start and example above.

I did some independent investigation on this and the problem is B.x is being imported as a global, and is in the export table as a global.