Improve mod resolution error for mods with multiple candidate files

[ytmimi]

Fixes #5167

When a.rs and a/mod.rs are both present we would emit an error
message telling the user that the module couldn't be found. However,
this behavior is misleading because we're dealing with an ambiguous
module path, not a "file not found" error.

Is the file a.rs or is it a/mod.rs? Rustfmt can't decide, and
the user needs to resolve this ambiguity themselves.

Now, the error message displayed to the user is in line with what they
would see if they went to compile their code with these conflicting
module names.

[calebcartwright]

Looks like a good improvement to me, thanks! For the sake of consistent tests across the variants, would you mind adding one that still triggers the file not found variant (I assume easiest way would be a test that had a path attribute on the mod import pointing to some non-existent file)

[ytmimi]

Good call! I'll get on that soon.

[ytmimi]

@calebcartwright I added additional tests to cover 3 different cases where a module might not be found. I also needed to modify the behavior I introduced in #5205 to surface the original error when the fallback doesn't work.

[ytmimi]

A slight improvement could be made to the existing behavior proposed in this PR.

In the currently implementation we'll always tell uses that foo.rs is missing (which is technically true if we reach a ModError::FileNotFound error), but if the foo directory exists it might be nicer to tell users that foo/mod.rs doesn't exist. The code to make the change is as follows (in the cotext of the match in src/modules.rs line 454):

                ModError::FileNotFound(_, default_path, secondary_path) => {
                    let file = if let Some(path) = secondary_path.parent() && path.exist() {
                        secondary_path
                    } else {
                        default_path
                    };
                    Err(ModuleResolutionError {
                        module: mod_name.to_string(),
                        kind: ModuleResolutionErrorKind::NotFound { file },
                    })
                }

to write the code more succinctly I've used the new let-chain feature, but I'm not sure if this PR should be the one to introduce that feature (#![feature(let_chains)]) to the project. I can certainly write the code without let-chain's if you think this is a worthwile improvement to what I've already got here, and I'm happy to write up some additional tests to cover cases where we'd inform users of a missing foo/mod.rs file.

[calebcartwright]

but I'm not sure if this PR should be the one to introduce that feature (#![feature(let_chains)]) to the project.

We've historically tried to stay away from using features, though I'm not entirely sure why to be honest. Not sure if I'm ready to take that plunge here, so let's keep that separate (can be addressed in a follow up PR if we decide to open that door)

[calebcartwright]

LGTM, thank you!

Will get back to regarding the potential introduction of the usage of gated features