[Chore] Add a changelog documenting the initial write of the LSP

Motivation and Context

Related Issue(s): None

We don't have a changelog documenting the initial features added to the language server. This is an empty MR with the sole purpose of adding such changelog.

✅ 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
• 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

Write a changelog to be included in the next LIGO release, since !2303 (merged) did not have it.

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

Add a new subcommand (ligo lsp) whose purpose is to allow LSP clients (Visual Studio Code, Emacs, Vim, etc) to communicate with the new LIGO Language Server, which is being rewritten in OCaml. This command is not meant to be launched manually by users, but rather by editors. The rewrite was officially made in !2303 (merged).

The initial release supports diagnostics (errors only), go to definition, hover, rename (only in open files), references (only in open files), and type definition.

As the rewrite is new, it does not yet support feature parity with the old language server, and bugs are to be expected.

Other LSP features (hover, folding range, document link, warnings for diagnostics, prepare rename) have since been implemented in other merge requests.

Official support for the Vim, Emacs, and Visual Studio Code plugins will come soon, as well as the VS Code plugin release on the Marketplace and OpenVSX.

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).