[#2183] Add LSP runtime analytics

Motivation and Context

This MR makes the following changes:

• Slightly refactor prometheus_push to avoid the usage of Lwt_main.run, which crashes the language server.
• Crashes could still spam the user with messages, so they are now a bit better handled. This is also useful for crash metrics.
• If the user uses the "LIGO: Restart LIGO LSP server" in VSCode, it will count as a restart and increment the crash metric.
• Methods are now (naïvely) timed and these times are collected every 5 minutes.
• If the compiler or language server crashes, it will also count the number of crashes received.

Analytics are sent only if the user has agreed to let LIGO collect them.

Related issues

Resolves #2183 (closed).

✅ Checklist for the LIGO Language Server

• I checked whether I need to update the README.md file for the plugin and did so if necessary:
  • If I implemented a new LSP request, I added it to the list of supported features that may be disabled
  • If I implemented a new LSP method, I added it to the list of supported functionality
• I checked that my changes work in Emacs, Vim, and Visual Studio Code
• (Before merging) The commit history is squashed and prettified, and follows the Serokell commit policy, or the MR is set to squash the commits

Description

Check commit messages for a description of changes.

Component

• compiler
• website
• webide
• vscode-plugin
• debugger

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Performance improvement (non-breaking change that improves performance)
• None (change with no changelog)

Changelog

The language server can now collect analytics such as the number of restarts, execution time of methods, and number of crashes. Analytics are sent only if the user has agreed to let LIGO collect analytics.

Crashes should be a bit better handled too.

Checklist:

• Changes follow the existing coding style (use dune @fmt to check).
• Tests for the changes have been added (for bug fixes / feature).
• Documentation has been updated.
• Changelog description has been added (if appropriate).
• Start titles under ## Changelog section with #### (if appropriate).
• There is no image or uploaded file in changelog
• Examples in changed behaviour have been added to the changelog (for breaking change / feature).