turbo

fc5e2b0d - chore: no longer convert in relative unix path constructor (#5552)

chore: no longer convert in relative unix path constructor (#5552) ### Description To quote @gsoltis: > In general: > - constructors should validate, to the extent they can (not much for `unix` paths, but can verify relative) > - conversions should be explicit. You need to know where you're starting from. If this were an AnchoredSystemPath on windows, the `\` -> `/` makes sense. If it's a literal from e.g. a tar file, then it doesn't. Reviewers Notes: - Opening up this PR in VSCode and using `Find All References` on the constructor is useful for double checking that I didn't miss a conversion. - Clippy error appeared on local when I made these changes. Fixed it just in case that would block CI - Moved `to_unix` to `AnchoredSystemPath` instead of `AnchoredSystemPathBuf` now that we have deref coercion which will automatically convert `&AnchroedSystemPathBuf` to `&AnchoredSystemPath` and moving the method allows it to be called from either type. ### Testing Instructions Looked through all uses of `RelativeUnixPathBuf::new` to see if there were places that depended on the conversion. The only use that was obvious was the usage in `cache_archive/create.rs`. `dotEnv` was the only other place where we possibly were converting a system path to a relative unix. We don't specify that `dotEnv` entries should be unix relative, so we might've been accidentally supporting system paths, but --------- Co-authored-by: Chris Olszewski <Chris Olszewski>