fix: remove .xcodeproj path component from most paths

[fortmarek]

Dependency and project paths currently include the .xcodeproj component, such as some-path/project/Project.xcodeproj. However, in tuist/tuist, project paths usually reference to some-path/project without the Project.xcodeproj. This PR aligns the mapper with this convention.

When the path to .xcodeproj is needed, we can still use the xcodeProjPath of Project.

cc @ajkolean

[pepicrft]

Dependency and project paths currently include the .xcodeproj component, such as some-path/project/Project.xcodeproj. However, in tuist/tuist, project paths usually reference to some-path/project without the Project.xcodeproj. This PR aligns the mapper with this convention.

I wonder how explicit we should be in the API regarding the graph being for generation vs loaded from a file-system Xcode project. Will we end up with assumptions at upper levels like this one, where it's a bit ambiguous what the path refers to?

[fortmarek]

I wonder how explicit we should be in the API regarding the graph being for generation vs loaded from a file-system Xcode project. Will we end up with assumptions at upper levels like this one, where it's a bit ambiguous what the path refers to?

I think the structure of the two should be aligned. At some point, we can add acceptance tests that ensure that the graph loaded from Project.swift is equal to the graph that's loaded after tuist generate using the XcodeProjMapper.

Unfortunately, in types like AbsolutePath there is no statically-typed way to ensure paths for example don't include .xcodeproj. We could also add some runtime assertions for things like this.

In other words, I agree with you this is an issue, but once the XcodeProjMapper is more stable, I don't think we'll run into these things too often.