resolve: mark it undetermined if single import is not has any bindings

- Fixes rust-lang#124490
- Fixes rust-lang#125013

This issue arises from incorrect resolution updates, for example:

```rust
mod a {
    pub mod b {
        pub mod c {}
    }
}

use a::*;

use b::c;
use c as b;

fn main() {}
```

1. In the first loop, binding `(root, b)` is refer to `root::a::b` due to `use a::*`.
    1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`.
    2. Then, the `imported_module` for `use c as b` will be recorded.
2. In the second loop, `use b::c` will be processed again:
    1. Firstly, it attempts to find the `path_res` for `(root, b)`.
    2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator.
    3. Use the binding `(root, b)` -> `root::a::b` introduced by `use a::*` and ultimately return `root::a::b` as the `path_res` of `b`.
    4. Then define the binding `(root, c)` -> `root::a::b::c`.
3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root::a::b::c`, ultimately causing inconsistency.

In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding.

r? `@petrochenkov`

Rollup of 7 pull requests

Successful merges:

 - rust-lang#122192 (Do not try to reveal hidden types when trying to prove Freeze in the defining scope)
 - rust-lang#124840 (resolve: mark it undetermined if single import is not has any bindings)
 - rust-lang#125622 (Winnow private method candidates instead of assuming any candidate of the right name will apply)
 - rust-lang#125871 (Orphanck[old solver]: Consider opaque types to never cover type parameters)
 - rust-lang#125893 (Handle all GVN binops in a single place.)
 - rust-lang#125911 (delete bootstrap build before switching to bumped rustc)
 - rust-lang#125918 (Revert: create const block bodies in typeck via query feeding)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup of 7 pull requests

Successful merges:

 - rust-lang#122192 (Do not try to reveal hidden types when trying to prove Freeze in the defining scope)
 - rust-lang#124840 (resolve: mark it undetermined if single import is not has any bindings)
 - rust-lang#125622 (Winnow private method candidates instead of assuming any candidate of the right name will apply)
 - rust-lang#125871 (Orphanck[old solver]: Consider opaque types to never cover type parameters)
 - rust-lang#125893 (Handle all GVN binops in a single place.)
 - rust-lang#125911 (delete bootstrap build before switching to bumped rustc)
 - rust-lang#125918 (Revert: create const block bodies in typeck via query feeding)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup of 7 pull requests

Successful merges:

 - rust-lang#122192 (Do not try to reveal hidden types when trying to prove Freeze in the defining scope)
 - rust-lang#124840 (resolve: mark it undetermined if single import is not has any bindings)
 - rust-lang#125622 (Winnow private method candidates instead of assuming any candidate of the right name will apply)
 - rust-lang#125871 (Orphanck[old solver]: Consider opaque types to never cover type parameters)
 - rust-lang#125893 (Handle all GVN binops in a single place.)
 - rust-lang#125911 (delete bootstrap build before switching to bumped rustc)
 - rust-lang#125918 (Revert: create const block bodies in typeck via query feeding)

r? `@ghost`
`@rustbot` modify labels: rollup

…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#124840 (resolve: mark it undetermined if single import is not has any bindings)
 - rust-lang#125622 (Winnow private method candidates instead of assuming any candidate of the right name will apply)
 - rust-lang#125648 (Remove unused(?) `~/rustsrc` folder from docker script)
 - rust-lang#125672 (Add more ABI test cases to miri (RFC 3391))
 - rust-lang#125800 (Fix `mut` static task queue in SGX target)
 - rust-lang#125871 (Orphanck[old solver]: Consider opaque types to never cover type parameters)
 - rust-lang#125893 (Handle all GVN binops in a single place.)
 - rust-lang#126008 (Port `tests/run-make-fulldeps/issue-19371` to ui-fulldeps)
 - rust-lang#126032 (Update description of the `IsTerminal` example)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#124840 - bvanjoi:fix-124490, r=petrochenkov

resolve: mark it undetermined if single import is not has any bindings

- Fixes rust-lang#124490
- Fixes rust-lang#125013

This issue arises from incorrect resolution updates, for example:

```rust
mod a {
    pub mod b {
        pub mod c {}
    }
}

use a::*;

use b::c;
use c as b;

fn main() {}
```

1. In the first loop, binding `(root, b)` is refer to `root::a::b` due to `use a::*`.
    1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`.
    2. Then, the `imported_module` for `use c as b` will be recorded.
2. In the second loop, `use b::c` will be processed again:
    1. Firstly, it attempts to find the `path_res` for `(root, b)`.
    2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator.
    3. Use the binding `(root, b)` -> `root::a::b` introduced by `use a::*` and ultimately return `root::a::b` as the `path_res` of `b`.
    4. Then define the binding `(root, c)` -> `root::a::b::c`.
3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root::a::b::c`, ultimately causing inconsistency.

In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding.

r? ``@petrochenkov``