Fix "Not en entrypoint" errors pointing to the wrong entrypoint

Motivation and Context

In the following code, entry1 is a valid entrypoint, but entry2 is not: it has 3 inputs while it should only have 2. (This can be fixed by replacing the two first arguments _i1: int, _i2: int by a single one [_i1, _i2]: [int, int].)

type storage = int;

type return_ = [list<operation>, storage];

const noop: list<operation> = list([]);

@entry const entry1 = (_i: int, _store: storage): return_ => [noop, 1]

@entry
const entry2 = (_i1: int, _i2: int, _store: storage): return_ => [noop, 1]

The compiler error wrongly pointed to entry1:

6 |
7 | @entry const entry1 = (_i: int, _store: storage): return_ => [noop, 1]
8 |Not an entrypoint: [_i, _store]int -> int -> ( list (operation) * int )

The compiler error now correctly points to entry2:

9 | @entry
10 | const entry2 = (_i1: int, _i2: int, _store: storage): return_ => [noop, 1]Not an entrypoint: [_i1, _i2, _store]int -> int -> int -> ( list (operation) *
int )

Description

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

If an entrypoint signature was wrong, the diagnostic was on the first entrypoint. Now it's fixed and target the wrong one.

Checklist:

• If a new syntax has been introduced, put a message on slack ligo-lsp
• 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).