[Suggestion] Allow opting out of Native Imports

[DuncanUszkay1]

Currently with the --use argument in asc we can replace implementations of the STD with our own- however in certain cases it'd be really nice to be able to prevent the module from being imported at all. I think this feature is important for AssemblyScript to be host-agnostic, since auto-importing features that may only make sense in a browser is unfriendly to those of us who aren't running in a browser.

This is useful when you know ahead of time that a module like Date won't be available in the host. In those cases, you'd want compilation to fail if you tried to reference Date in your program or it's dependencies.

From a compiler perspective it can be implemented by just removing the elementsByName entry associated with the import that we don't want when the asc options indicate the import isn't wanted. Afterwards we get a nice error message (or at least nicer than having it blow up later on the host):

ERROR TS2304: Cannot find name 'Date'.

 Date.now();
 ~~~~
 in main.ts(1,1)

In terms of the syntax of this I have a few ideas:

--unload Date <OtherName> ...
--use Date=
--use Date=None

Let me know if you think this feature would make sense, or if you have any other suggestions to make this more friendly to non-browser hosts.

If this sounds good I'll gladly throw up a PR

[dcodeIO]

I like the --use Date= suggestion to disable adding the default, as it aligns well with --use abort=. Conceptionally it's a bit different from what's done for abort, though, in that it would undo what a top-level export in a ~lib file implies, while the default for --use abort is specified by the frontend. As a start, I think that undoing the implied default is fine.

I have also been thinking to revise that mechanism in general eventually. So, perhaps, since this suggestion touches the mechanism somewhat, let me explain a bit to give some context independent of implementing the initial suggestion, just in case an opportunity of foresight turns up right away.

There are currently multiple ways of making an element a global:

1. export from a top-level library file
2. Annotating with the @global decorator
3. Specifying a --use argument on the CLI

Now, the @global decorator is something we should get rid of, as it currently requires parsing all the library files to find them, but then we need an alternative mechanism to achieve the same. That alternative mechanism cannot be export from a top-level library file obviously, so I began to wonder if we can instead introduce a more general mechanism, potentially replacing all of the above. Again, this is mostly for context, but thought I mention just in case.