Rework ManimGL version detection

[Splines]

Closes #119.

Manim Version detection

The previous approach of how to detect the user's Manim version was brittle and very slow since we directly called manimgl --version and also spawned a separate VSCode Terminal. Instead, we now use the child_process.exec() function from Node.js directly and execute the following command in the background:

<pythonBinary> -c "from importlib.metadata import version; print(version('manimgl'))"

From some manual timing-tests, we see that this only takes less than 80ms compared to 1.8s of manimgl --version (of course on my machine and only a few runs).

Why do we need the ManimGL version?

We need it to decide on several things, e.g.

• Are we able to call manimgl with the new --autoreload CLI flag? If the user has an older version of ManimGL installed, we don't want to include --autoreload, since then ManimGL would not even start correctly and complain about the unknown flag.
• Is the new reload() command available inside the IPython shell? Admittedly, for this, we could also send this Python command instead: print("For this functionality, ManimGL vX.X.X is required.") if 'reload' not in globals() else reload(). However, with our detection logic we have the possibility to better integrate into the VSCode framework, i.e. show an information message with a button to let the user try determining the version again or even opening our walkthrough containing an installation guide.
• (We will probably need this for other upcoming features of the extension that rely on some new Manim functionality.)

More benefits:

• If users don't have the latest version installed, they will be notified. This is especially useful if you're working with multiple Manim installations locally. By being informed about the version used, you can avoid errors where the user thinks that a specific Manim installation is used (while in reality it's another one).

Known limitations

• Won't detect any other version strings than those in the format "1.2.3". Should 3Blue1Brown decide that they start with release candidates and the like, we need to adapt the logic a bit to determine what a "newer" version is.
• Calls to the Manim Notebook extension are now non-blocking, i.e. other extension commands can already register, while we determine the version in the background. But you might still think that it takes quite some time for the extension to activate. This is due to:
  • VSCode activating the extension on our defined activation events (have a Python file open). And even if you have such a file open, VSCode might activate other extensions first. We have no control over the order of extension activation.
  • Before the Manim version is detected and the Windows paste patch applied, we still have to wait for the Python extension to be fully loaded (in the background). This is such that we can adapt the paths should the user be in a virtual environment (something that the Python extension will tell us after it has started up).
• Also note that we won't detect if the user switches venv; they will have to reload the window such that we can correctly work with the new version. Luckily, switching venvs is not something that occurs that frequently.

---

Reviewers

There are many different code paths, please try to test them all, by manually inserting statements. E.g. one scenario is: Manim version could not be determined at the beginning, but after "Try again" it can be determined. Or another: Manim version could not be determined, user clicks on Preview & Reload, warning message shows up, user clicks on "Try to determine again", then version is determined and command should work now. Etc.

[Splines]

@mitkonikov So with this PR, I've made startup a lot quicker, see the description. Hopefully this is what you had in mind with #119. Feel free to give a review. Tests are now also starting up quicker in VSCode locally, yeah ;)

[mitkonikov]

OMG! @Splines Now we are talking! This is amazing! Everything is super fast and super slick! Also, all tests pass locally on Windows now! Great job! Let me just check the code, if there are some details left to be improved, but either way, it's awesome!

[Splines]

Will come back to this later today or tomorrow with fresh eyes to look over the code changes again, before I merge this.

[mitkonikov]

LGTM! You can simplify the python.exe to the python alias in Windows. Other than that merge it.