Rewrite error-trace view with VSCode Webview UI toolkit

[lemmy]

https://code.visualstudio.com/blogs/2021/10/11/webview-ui-toolkit

#260
#259
#258
#257
#256
#255
#250
#239
#229
#215
#164

[afonsonf]

Hi, I'm available to work on this one.

My proposal would be to start migrating the check-result-view "as it is" to the webview toolkit component library following the "default samples" (https://github.com/microsoft/vscode-webview-ui-toolkit-samples). This is replacing current ui elements with equivalent webui components and moving the current ui code to typescript.

After that the ui design could be changed to address the listed issues.

[lemmy]

@afonsonf It would be beneficial to determine the scalability of the webview-ui-toolkit early in the process. Currently, the HTML-based viewer tends to have slow rendering times when dealing with extensive traces (comprising hundreds of states) and intricate states (involving dozens of variables). Additionally, I recall implementing a viewport feature in the past for the older Toolbox to manage lengthy traces.

[afonsonf]

Created here some specs to stress test the extension: https://github.com/afonsonf/vscode-tlaplus-stress-specs
In my pc, using the current version of the extension in codespaces, I can run the BigState spec until around the counter 40 and the BigTrace until around the counter 500, I would use those values as the base to achieve in the refactoring

Current state of the refactoring can be checked in the following branch (Buttons, run status, states and coveragestats done): https://github.com/afonsonf/vscode-tlaplus/tree/refactor-webview-using-vscode-toolkit

In my current implementation I made the webview stateless, does not require the state to be sent by the extension as a message, this means all the html is generated in the extension side, and not "filled" in the webview side, but still need to do some tests to check if it is better or not, if not those classes can easily be reused to "fill" the html in the webview side