When a variable is not in the current scope, an `Error::UnknownVariable`
is triggered. However the only suggestions were for variables in the
scope with a similar name computed by the "did you mean" algorithm. With
this commit, we also suggest public and internal values (such as
constants, functions or type variant constructor) in imported modules
with the same name.

For example with the following code:
```gleam
import gleam/io

pub fn main() -> Nil {
println("Hello, World!")
}
```

The suggestions are:
```
┌─ /path/to/project/src/project.gleam:4:3
│
4 │ println("Hello, World!")
│ ^^^^^^^

The name `println` is not in scope here.
Consider using one of these variables:

io.println
```

However because we are only checking the name and the arity, we could
have wrong suggestions, as in this case:
```gleam
import gleam/float
import gleam/int

pub fn main() -> Nil {
to_string(3)
}
```

Here, it is clear that we want suggestions on a function named
`to_string` and accepting one parameter of type `Int`, but this is not
the case:
```
┌─ /path/to/project/src/project.gleam:5:3
│
5 │ to_string(3)
│ ^^^^^^^^^

The name `to_string` is not in scope here.
Consider using one of these implementations:

float.to_string
int.to_string
```

In this case, even if the arity is correct, the type of arguments can
mismatch, resulting in incorrect suggestions.

Suggestions also works on pipelines but there are subtleties. Function
calls are considered to be always of arity `arguments.len() + 1`.

In this code, the arity of `to_string` function is considered to be 1.
```gleam
1 |> to_string
```

And in this code, the arity of `to_string` function is considered to
be 2:
```gleam
1 |> to_string(2)
```

This is hard to make something better without analyzing the return
type because function call in pipeline can be desugared into two
possibilities. For example, take this code:
```gleam
1 |> add(2)
```

It can be desugared in these two forms:
```gleam
add(1, 2)
add(2)(1)
```

As it stands, this is not possible to make better suggestions without
adding more analysis on the return type.

Add better unreachable code warnings when a panic is before a use
expression.

With previous changes, a test was broken when a panic was right before a
use expression. The test was like that:
```gleam
pub fn wibble(_) { 1 }

pub fn main() {
panic
use <- wibble
1
}
```

This was the case because, before these changes, `UntypedExpr::Var`
has not special call path in `do_infer_call` function. `infer` and
`infer_or_error` was called has expected and a warning was emitted by
`warn_for_unreachable_code` in case of a previous panic expression.

Actually, `UntypedExpr::FieldAccess` has a special call path in
`do_infer_call` and compiler does not warned about a program like that:
```gleam
// Define pub fn wibble(_) { 1 }
import mylib/mymod

pub fn main() {
panic
use <- mymod.wibble
1
}
```

With this change, use expression are always warned after a panic
expression.

For this change, we add to renamed all functions in `ModuleInterface`
from `get_public_*` functions to `get_importable_*` because we wanted
to suggests internal value only from modules of the same package,
otherwise we should suggest only public values. Before this change, all
`get_public_*` functions was returning `importable` values which are
internal and public.

Because the naming was not the best one for these functions, we have
renamed them to `get_importable_*` which seems more appropriate.

If you run `gleam remove` in a project that's never been built (or
where someone deleted manifest.toml while sorting out a dependency
mess) the command crashes with a generic File IO error coming from
the manifest read inside cleanup(). gleam.toml itself doesn't get
updated.

Skip the cleanup when manifest.toml doesn't exist. There's nothing
to clean up in that case and the next build will regenerate it
anyway.

Closes #5654.

Signed-off-by: Charlie Tonneslan <cst0520@gmail.com>

Co-authored-by: Louis Pilfold <louis@lpil.uk>

Co-authored-by: Louis Pilfold <louis@lpil.uk>

Co-authored-by: Louis Pilfold <louis@lpil.uk>

[gen-lsp-types](https://github.com/ribru17/gen-lsp-types) is an
alternative to the lsp-types crate, with types generated via codegen
from the official LSP Metamodel for correctness and completeness.

lsp-types issues fixed in gen-lsp-types:

- https://github.com/gluon-lang/lsp-types/issues/310
- https://github.com/gluon-lang/lsp-types/issues/308
- https://github.com/gluon-lang/lsp-types/issues/284
- https://github.com/gluon-lang/lsp-types/issues/278
- https://github.com/gluon-lang/lsp-types/issues/277
- https://github.com/gluon-lang/lsp-types/issues/260
- https://github.com/gluon-lang/lsp-types/issues/245
- https://github.com/gluon-lang/lsp-types/issues/93

See: https://github.com/wgsl-analyzer/wgsl-analyzer/pull/1090 and
https://github.com/rust-lang/rust-analyzer/pull/22115

It doesn't fully resolves the issue ATM: I need to implement incrementing of counter for generated var

escape_path only escaped backslashes, not double-quote characters.
Since paths are embedded in an Erlang string literal sent to the
compile escript, a filename containing " could break out of the
string delimiter and produce a malformed module list.