Deprecate the SAWScript `main` feature

[sauclovian-g]

SAWScript has a feature where after loading and executing a file, if it finds something called main in the global environment it then executes that.

This feature is not widely known, not widely used, and does not serve any real purpose.

Handling the panic in #2556 (in which this would try to execute anything, whether or not it was executable) also revealed that it's almost entirely undocumented. Furthermore, the checks require to avoid the panic while not also making the identifier main effectively reserved are annoying, complicated, and probably not very robust.

Rather than wasting energy documenting it, it seems like it might be a better idea to just deprecate the feature.

It's not a builtin but we can use the same process: initially if we find an executable main warn and execute it, later if we find an executable main fail, then delete the code entirely.

[RyanGlScott]

My only hesitation in deprecating SAW's main is that it might serve a purpose similar to Python's __main__. Namely, it might be the case that if you run a SAW script directly from saw, then it will execute main, but if you import a SAW script from another script, then main might not get executed. (I am using the word "might" a lot here—I haven't confirmed if this is actually the case or not.) If this is the case, then one could make the argument that main does serve a real purpose, even if it is currently undocumented.

[sauclovian-g]

It is not the case, alas, it'll just run whatever it finds called main, and since there's no module system whatsoever, there's no (simple) way to exclude ones that appeared via include.

However, that would be useful functionality to have. Perhaps there's a non-horrible way to get there without going and building a whole module system.

[sauclovian-g]

Update: there are more uses than we'd originally thought, so we need a replacement.

The current feature is also nonetheless broken. We could add further magic behavior to the main identifier so mains defined in included files get ignored (making it effectively reserved as noted in the original issue text), or we could add something different that works like Python __main__. I prefer the latter.

It should be workable to define a magic identifier called __main__ or __is_main__ of type Bool that is true if and only if the current execution is not in an included file. (It can't just be a builtin, because by the time builtins run includes have been included and the interpreter doesn't know if it's in one. We could add frobs so the interpreter can know that, but it seems better and perfectly reasonable to just recognize and substitute for the identifier during include processing.

Then the usage is like this:

if __main__ then do {
   stuff;
};

except there's a wrinkle: the parser doesn't accept if with no else. We could fix that, or we could do something else.

Another option is to keep the current behavior of main being a function, except call it __main__ and make it reserved and magic. Then the usage is

let __main__ = do {
   stuff;
};

Uses in include files would get turned into let _ : TopLevel () = ... so they still have to typecheck but don't get run.

I kind of prefer the if-based one, because it's more flexible; e.g. it doesn't limit you to one main block and doesn't insist that the main block runs after everything else. And it also allows running things in non-main files, although there's no clear use case for that.