universal-lock: if we write file paths to a lock file, we need to make them portable

[BurntSushi]

While working on #4266, I realized that the file paths we write to a lock file are platform specific. Specifically, on Windows, we use \ as a path separator, while on Unix, we use / as a path separator. I believe this implies that if developers on Windows and Unix work on the same project, they will generate different lock files. This is, I believe, untenable.

I think we either need to find a way to not write file paths to a lock file at all (this is what Cargo does), or we need to ensure we normalize all file paths into a portable representation.

It's not clear to me that the latter is strictly possible in all cases, but I think we are always writing Unix paths to requirements.txt by either converting \ to /, or using file URLs.

[zanieb]

See also #3804

[charliermarsh]

In the interim, should we just call to_slash on the paths? That library exists for this purpose IIRC.

[BurntSushi]

Closed by #4324.

We should perhaps still explore the design space of "don't write paths to a lock file," but Charlie makes the point that this would require reading the pyproject.toml in order to understand the lock file. I believe, at present, the lock file is "hermetic," which could be conceivably useful (and it is at least conceptually simpler). My very vague thinking on the matter at present is the following:

1. I wouldn't be surprised if we wind up needing to read pyproject.toml and give up the hermetic lock file approach for some other reason. But I don't know what that reason is yet.
2. I have a nagging suspicion that even by converting paths to Unix paths, there are still some cases that we'll get wrong in the sense that it isn't portable. But I'm finding it difficult to articulate those cases since, even if the paths aren't in the lock file, they have to be somewhere (like pyproject.toml, which needs to be valid UTF-8 and thus inherently already prevents some kinds of file paths from being expressible as-is).