📦 Fix nested umbrella header handling

[danieleformichelli]

Resolves #3459

Short description 📝

Nested umbrella headers should be handled as umbrella headers (adding the headers to the build phase instead of using the module map)

Checklist ✅

• The code architecture and patterns are consistent with the rest of the codebase.
• The changes have been tested following the documented guidelines.
• The CHANGELOG.md has been updated to reflect the changes. In case of a breaking change, it's been flagged as such.
• In case the PR introduces changes that affect users, the documentation has been updated.
• In case the PR introduces changes that affect how the cache artifact is generated starting from the TuistGraph.Target, the Constants.cacheVersion has been updated.

[pepicrft]

It'd be great to get @kwridan's eyes on this one

[kwridan]

Thanks @danyf90

If I followed along the nestedHeader is the case is what GoogleSignIn has

e.g.

GoogleSignIn/Sources/
├── .....
├── Public
│   └── GoogleSignIn
│       ├── GIDAuthentication.h
│       ├── GIDConfiguration.h
│       ├── GIDGoogleUser.h
│       ├── GIDProfileData.h
│       ├── GIDSignIn.h
│       ├── GIDSignInButton.h
│       └── GoogleSignIn.h

And GoogleSignIn.h is the umbrella header. From that perspective the changes make sense - to expose those as public headers instead of using a custom module map.

Inspecting the GoogleSignIn project in isolation I see some of the other headers are missing - is that expected?

e.g.

Original (stand alone generated using swift package generate-xcodeproj

vs. tuist generate

[danieleformichelli]

Hey @kwridan 👋
Thanks for the review!

Regarding the missing headers, the public ones are only the ones we have added, while other ones are referenced locally via the header search path.
We could add them to the project as additional files to be shown in Xcode, but I think it is outside of the scope of this PR