Fix -Zremap-path-scope rmeta handling

[Urgau]

This PR fixes the conditional remapping (-Zremap-path-scope) of rmeta file paths by using the debuginfo scope by conditionally embedding the local path in addition to the remapped path.

Fixes #139217

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[fmease]

Looks fine to me but I'm not an expert here and I'm wondering if it needs to be DEBUGINFO | DIAGNOSTICS over just DEBUGINFO.

[Urgau]

After more investigation I was finally able to figure out the real issue, when we embed the paths in the rmeta files we call PathMapping::to_embeddable_absolute_path, that function does the necessary to create a remapped path when possible BUT when doing so that function does not keep the original un-remapped path.

This was done before -Zremap-path-scope introduction and means that when we are in a subsequent crate we only have access to the remapped path even through we might want the un-remapped path (depending on the remap path scope), which lead to the issue described in #139217 where the path of the dependency was un-conditionaly the remapped one, because that's all we got.

I've added to PathMapping and PathMapping::to_embeddable_absolute_path some logic to keep the local path when not all remap path scope are requested, as to keep rlib and rmeta free of local path when only --remap-path-prefix is passed (privacy and build reproducibility reasons).

@rustbot labels -S-blocked -S-waiting-on-author +S-waiting-on-review

[fmease]

I don't have the capacity to properly review this right now and verify everything is correct.
r? compiler

[fmease]

Esteban isn't that active rn afaik.
r? compiler