chore: extract and include LS release notes inside the changelog

Description

A VSCode release often includes a language server version bump which introduces new features, fixes and changes to the extension.

However, since this is just a simple chore(deps) change on the VS Code side, they are not reflected in the VSCode changelog. This leads to uncertainty in what a VSC release actually provides to users.

This MR introduces new template for the VSCode changelog and release rules

• Following similar template to gitlab-lsp, include all of the commits in the VSCode changelog. Currently, we only include feature and fix commits which makes the VS Code changelog look quite empty even though the release contains many other changes.
• A release can be created on any type of commits
  • no longer required to have :feat or :fix commits to release
• Detect the LS version difference in the VSCode release. If there is a LS version bump, extract corresponding changelog and include in the VS Code changelog.

Related Issues

Resolves #2102 (closed)

How has this been tested?

• If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
• Consider an end-to-end test for significant new features that aren't covered by integration tests.

1. Check out this branch

2. Apply this patch

   diff --git a/release.config.js b/release.config.js
   index db7a5be7..96f09d71 100644
   --- a/release.config.js
   +++ b/release.config.js
   @@ -4,7 +4,7 @@ const releaseType = isPrerelease ? 'pre-release' : 'release';
    const headerPartial = `{{#if isPatch~}}  ##{{~else~}}  #{{~/if}} **${releaseType}**  {{#if @root.linkCompare~}}  [{{version}}](  {{~#if @root.repository~}}    {{~#if @root.host}}      {{~@root.host}}/    {{~/if}}    {{~#if @root.owner}}      {{~@root.owner}}/    {{~/if}}    {{~@root.repository}}  {{~else}}    {{~@root.repoUrl}}  {{~/if~}}  /compare/{{previousTag}}...{{currentTag}}){{~else}}  {{~version}}{{~/if}}{{~#if title}} "{{title}}"{{~/if}}{{~#if date}} ({{date}}){{/if}}`;
    
    module.exports = {
   -  branches: 'main',
   +  branches: ['main', '2102/include-LS-logs-inside-changelog'],
      plugins: [
        [
          '@semantic-release/commit-analyzer',
   @@ -138,37 +138,37 @@ module.exports = {
            message: 'chore(release): ${nextRelease.version}\n\n${nextRelease.notes}',
          },
        ],
   -    [
   -      '@semantic-release/gitlab',
   -      {
   -        assets: [
   -          {
   -            path: 'dist-desktop/*.vsix',
   -            label: 'gitlab-workflow-${nextRelease.version}.vsix',
   -            target: 'generic_package',
   -            type: 'package',
   -          },
   -        ],
   -      },
   -    ],
   -    [
   -      'semantic-release-slack-bot',
   -      {
   -        notifyOnSuccess: false,
   -        notifyOnFail: false,
   -        markdownReleaseNotes: true,
   -        slackWebhookEnVar: 'SLACK_WEBHOOK',

3. Run semantic-release --dry-run

   • This will run a test run of semantic-release showing a preview of the pending release while printing the next version release notes to the console

Screenshots (if appropriate)

before	after
	Expected release note entry in changelog (result of semantic-release --dry-run )

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes