Manually cherry-pick fix for normalize_path()

[SomeTiramisu]

As discussed in #2510 (comment)
normalize_path() was copied from Cargo before commit
rust-lang/cargo@7a6eaf9
which had an issue with ..s in processor output path (at least). This prevent
meson, or any exotic build environment to cache preprocessed objects.

This PR manually cherry pick the fix, but lack any associated test (yet)

[AJIOB]

Hi @SomeTiramisu ,

Please, add the test to exclude the possible regression for that.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.32%. Comparing base (68cd330) to head (2e6ff15).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2751      +/-   ##
==========================================
+ Coverage   74.18%   74.32%   +0.14%     
==========================================
  Files          71       71              
  Lines       40491    40709     +218     
==========================================
+ Hits        30037    30258     +221     
+ Misses      10454    10451       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[SomeTiramisu]

Please, add the test to exclude the possible regression for that.

I'm new with the rust toolchain, so far I haven't found what obscure test triggered the Component::ParentDir => path. Since this does not fail with the patch, i assume there is no regression there. The worst I can do is return an even more invalid path.

What I can do is testing the improved accuracy of normalize_path() in case of ..; adding test cases in test_process_preprocessor_line_fs_access() that would fail before the patch.

Curiously, msvc.rs have it's own way of normalizing, clang.rs omit it completely

[SomeTiramisu]

It's whether I'm on the right track or completely lost. I fear going too deep for what looks like an edge case optimisation (allow preprocessor cache when include path contain a ..).

No more warning is a thing, but does this really improve performance? I still have to benchmark this (I will use mpc like in #2510 (comment))

[SomeTiramisu]

This now looks like a two in one PR. On one hand normalize_path() is now more correct with new code path tested. On the other hand process_preprocessor_line() now normalize on absolute path. The latter fix the original issue.

Benchmark on over optimistic scenario (full clean rebuild, same code) with sccache, on a meson project (GIMP in my case) shows improvement on build time (because preprocessor cache is now working) at the cost of a bit slower caching.

[SomeTiramisu]

Rebase on main, CI is happy, I'm now confident enought to make it a genuine PR

I still find the tests a bit too verbose for my taste