Various fixes, with a view toward the vscode extension

[pzinn]

This branch has two purposes:

• allow any user to run Macaulay2 in Macaulay2Web in local mode (npm start local) or more importantly to use Macaulay2 in the newly developed vscode extension, with the same quality of rendering as with the forked branch (vanilla) used on the official Macaulay2Web server.
• in the process, I've found quite a few commits that fell through the cracks, so I'm putting them here in the hope to have the vanilla branch and the main M2 branch converge in the near future.

This is very much work in progress.

[pzinn]

this gtest stuff is driving me insane. it seems each time I have a new commit, it silently changes gtest and it's not clear why / how to know about it.

[pzinn]

OK this might be enough for a PR.

• updated webapp.m2: lots of changes under the hood to improve M2Web/vscode extension.
• small changes to some output routines.
• hypertext FilePosition now produces a link, as discussed on zulip.
• changes to tex in webapp mode: M2 will now try harder to use direct html output rather than katex, so texMath is hacked to do so.
• an annoying issue is that M2 outputs with both stdout and stderr. That's not great when M2 is spawned as a sub-process and the output is forwarded, as is the case for M2Web and vscode extension, because the outputs of stdout and stderr are typically no longer in sync and error messages appear in the wrong place. There are two solutions:
  -- use a shell and redirect (2&>1 or whatnot). this is fine but creates additional technical issues that I was unable to resolve for the vscode extension (SIGINT is no longer forwarded to M2).
  -- not use stderr! so in the current PR, as a possibly temporary measure, stderr is redefined as stdout in webapp mode.
• a small unrelated commit fixing a problem with promotion of fraction fields, cf the discussion in Promotion issues #3184 and the added test.

[mikestillman]

A few notes about this.

• It compiled fine for me
• Using it in the vscode extension:
  • After e.g. help matrix, the example code is made into a series of buttons. That would be great, except it contains the prompt. the input, and also the output. So one gets errors when pressing such a button. (Maybe this was the case earlier too?)
  • On the plus side, the errors one gets do come out in the correct location!
• The promote changes seem good (and desirable) to me. I like the idea mentioned in the issue, of deprecating liftable, changing to isLiftable too.

@pzinn Do you want to make any other changes for the moment, before this gets accepted?

[mikestillman]

@d-torrance Do you see any issues with the changes to use of stdin and stderr? It seems that since this is done only for webapp mode, it should not be a problem?

[pzinn]

thanks for testing @mikestillman. Yeah it's not perfect yet (in particular when it comes to help and error messages), but it's an improvement over the current situation. In particular one thing which should work fine now is the links to code in say

code methods ideal

You're right that code in examples is not properly parsed -- unfortunately this is the way examples are currently produced, as a block rather than with separate input/output. On my vanilla branch, help examples are produced in webapp mode, which automatically inserts all the character codes that allow to distinguish say input from output.

I would say this PR is enough as it is. Unless there's a problem with it, it's ready to be merged.
I'll definitely work on a second one, but it will take some time because any further improvements require significantly more work.