std.Build.LazyPath: add sub path method

[RossComputerGuy]

Closes #16067

This implements joined lazy paths (sub path)

[lacc97]

Wouldn't this make it really easy to dangle a LazyPath since the parent now requires a stable address?

[RossComputerGuy]

Possibly, I could make the parent be a union similar to LazyPath so then this wouldn't be an issue. I can't make the parent be a LazyPath unless it was a pointer because recursion.

[lacc97]

How about adding a nullable subpath field to the LazyPath?

Ideally something like

const LazyPath = struct {
    subpath: ?[]const u8 = null,
    data: union(enum) {
        // ...
    },
};

but for backwards compatibility maybe flip it around and add the subpath to the other union fields instead?

Actually, wouldn't this only be needed for the generated* cases? Since the other union fields implicitly support subpaths given their payloads are already paths.

[RossComputerGuy]

Probably, that sounds like it'll work the best. I'll try things out after work today.

[castholm]

Does this implementation prevent something like path.subPath("../../../../secret.txt") from reaching outside of the root of the underlying path (zig-cache/ for generated paths, the build root for regular paths, cwd for cwd-relative paths, etc.) in the same way that LazyPath.dirname does? Protecting against this was an important concern for dirname, so I figure it is just as important here.

You might want to take a look at the dirname issue #17411 and the related PR that implemented it for inspiration. A few tests that verify the correctness of the behavior would probably be good as well.

[RossComputerGuy]

I don't think it does protect from that in its current state. I'll see if I can prevent escaping when I work on the changes tonight.

[RossComputerGuy]

Looking at how much would have to be changed, this is too much for now. Gonna close this PR, if someone wishes to finish this then I recommend some discussion on how this should be implemented so it doesn't break everything.