Repartition source roots after running build scripts

[jnkr-ifx]

I ran into the following issue:

I have a library crate which contains an (example) application crate in a subdirectory. The application depends on the library using a path dependency, and the library contains a build.rs which generates some code that is include!'d by the library.

Minimal reproduction

library/Cargo.toml:

[package]
name = "library"
version = "0.1.0"
edition = "2024"

[dependencies]

library/build.rs:

fn main() {
    std::fs::write(
        std::env::var("OUT_DIR").unwrap() + "/include.rs",
        r#"pub const FOO: &str = "hello, world";"#,
    )
    .unwrap();
}

library/src/lib.rs:

include!(concat!(env!("OUT_DIR"), "/include.rs"));

library/application/Cargo.toml:

[package]
name = "application"
version = "0.1.0"
edition = "2024"

[dependencies]
library = { path = ".." }

library/application/src/main.rs:

fn main() {
    println!("{}", library::FOO);
}

When running rust-analyzer within the application, the include! fails with the error "failed to load file /path/to/target/.../out/include.rs", despite the path being present on the disk; and definitions within the generated code are unavailable to RA.

I debugged the issue and found it to be a problem with VFS source root partitioning: include.rs was missing from library's source root.

Normally, when loading a workspace, RA:

1. Discovers files in each crate, excluding the target/ directory, and partitions them into the appropriate source roots
2. Runs each crate's build script, adding its output directory to the crate's source root configuration
3. Discovers files in the build script output directories

The discovery of the new files then causes the VFS to be repartitioned, ensuring the build script outputs are placed into the appropriate source roots.

However, this fails when crates are placed in this nested folder structure. Step 1 finds the build script outputs early (I think they're found when scanning the library/ crate, since library/application/target is not library's target directory and so is not skipped). By the time we get to step 3, all the files have already been discovered, and so we don't notice a change in the project structure and source root repartitioning does not get a chance to run with the configuration from step 2.

This PR fixes the issue by explicitly repartitioning source roots after changing the source root configuration.