feat: let all compiler errors carry a Location instead of a Span

[asterite]

Description

Problem

Resolves #7452
Resolves #7453

Summary

Another huge PR, but this one is simpler than the other one (it's more mechanical).

Now that most of the compiler code works with Location instead of Span, this PR makes all compiler errors carry a Location instead of a Span (when they carried spans).

With this, a lot is simplified:

1. When pushing errors we no longer need to specify in which file they happen, because each error knows its file
2. Consequently, the errors we track are just Vec<CompilationError> instead of Vec<(CompilationError, FileId)> because all errors have a location and so have a file.
3. In fact, the field file from Elaborator is no longer needed, so bugs that would happen because it wasn't updated can't happen anymore
4. Errors that mentioned multiple spans from potentially different files now mention multiple locations so their files can naturally be different

An example of 4 is this code:

// main.nr
mod other;

use other::Foo;

impl Foo {
    fn foo(self) {}
}

fn main() {}

// other.nr
pub struct Foo {}

impl Foo {
    pub fn foo(self) {}
}

The old error is:

error: duplicate definitions of foo found
  ┌─ src/other.nr:4:12
  │
4 │     pub fn foo(self) {}
  │            ---   --- first definition found here
  │            │
  │            second definition found here

The new error is:

error: duplicate definitions of foo found
  ┌─ src/main.nr:6:8
  │
6 │     fn foo(self) {}
  │        --- first definition found here
  │
  ┌─ src/other.nr:4:12
  │
4 │     pub fn foo(self) {}
  │            --- second definition found here

Additional Context

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[michaeljklein]

Remaining TODO but otherwise LGTM

Optionally, the two Location's in ExpressionKind::Unsafe could get mixed up so you could:

• Move one of the Location's to BlockExpression
• Make ExpressionKind::Unsafe a struct variant

[asterite]

@michaeljklein I created an UnsafeExpression struct. In the end only one of the locations ended up being used, but I think with the struct it's a bit clearer so I left it.

[jfecher]

LGTM - this change has been a long time coming.

Looks like we'll need to bump the maximum memory limit for private-kernel-tail

[michaeljklein]

LGTM