Move name resolution logic to a dedicated file

[cjgillot]

The code resolution logic from an Ident is scattered between several files.

The first commits creates rustc_resolve::probe module to hold the different mutually recursive functions together. Just a move, no code change.
The following commits attempt to make the logic a bit more readable.

The two fields last_import_segment and unusable_binding are replaced by function parameters.
In order to manage the fallout, maybe_ variants of the function are added, dedicated to speculative resolution.

r? @petrochenkov

[petrochenkov]

Some preliminary comments:

• It's not clear why "probe" was chosen as the name
• I'd prefer to move the fn report_error stuff to diagnostics.rs leaving other files primarily for "reference implementation of the language", if that makes sense
• It's unfortunate that multiple versions of functions like fn maybe_foo + fn foo + fn foo_with_ribs + etc have to be introduced as a replacement for having optional function parameters at language level. The "maybe" naming doesn't even reflect that we are simply omitting some parameters with default values.
  I wish there was a better way to address this, but the alternative of creating a separate new FooArgs struct for every such function is even more awful.

[cjgillot]

I believe this version addresses your first round of reviews. The refactor of resolve_path has been removed.

Some preliminary comments:

* It's not clear why "probe" was chosen as the name

Just because I found rustc_resolve::resolve silly. What would you prefer?

* I'd prefer to move the `fn report_error` stuff to diagnostics.rs leaving other files primarily for "reference implementation of the language", if that makes sense

Done.

* It's unfortunate that multiple versions of functions like `fn maybe_foo` + `fn foo` + `fn foo_with_ribs` + etc have to be introduced as a replacement for having optional function parameters at language level. The "maybe" naming doesn't even reflect that we are simply omitting some parameters with default values.
I wish there was a better way to address this, but the alternative of creating a separate new `FooArgs` struct for every such function is even more awful.

I understand the maybe_ version to be suitable for speculative resolution. Is it correct with those parameters?

[petrochenkov]

Just because I found rustc_resolve::resolve silly. What would you prefer?

Well, if we have macros.rs for macro-specific stuff, and imports.rs for import-specific stuff, them maybe we should have ident(s).rs for identifier resolution stuff (which I see moved to this new file).

(resolve_path(_with_ribs) should ideally be a nearly trivial loop over resolving identifiers, so it doesn't deserve its own file or file naming.)

[petrochenkov]

r=me with #95405 (comment) applied.

[cjgillot]

@bors r=petrochenkov

[bors]

📌 Commit 276b946 has been approved by petrochenkov