Fix framework to package /Modules files when built

[thedavidharris]

Public headers were added to the xcodeproj file in a way that a modulemap was no longer being generated, and therefore no swiftmodule (or swiftinterface) file could be created. This adds them as explicit public headers instead of a folder copy.

Addresses https://github.com/datatheorem/TrustKit/issues/222

[nabla-c0d3]

The problem has been that it's difficult to get to a setup that works for the three different package managers we support:

1) Swift Package Manager 2) Carthage 3) CocoaPods

When we added 1) it broke 2) and 3) (#220 #214). We fixed 3) which then broke 1). We fixed it too but now 2) is still broken. This is not validated in the test suite so I am worried that merging this will just break one of them again.

[adamkaplan]

Ouch. That sounds super painful. Maybe the contributor can separate CI tests for Carthage and SPM

[thedavidharris]

I didn't want to do anything drastic but what I would generally suggest:

• Follow the SPM defaults and use /include for public headers. Then things should be pretty clean by default
• CocoaPods and SPM both build off the file system, so CocoaPods can follow the SPM defaults
• Carthage just needs a valid xcodeproj file to build off of. As was the case here, this didn't change the filesystem at all, but the way the files were added to the xcodeproj weren't valid: adding the folder doesn't actually add the files to the xcodeproj file for publich headers, but since nobody is consuming those, it works fine (this pitfall technically exists with the others as well).

I wouldn't worry about specific tests around all the package managers to be an issue unless there are going to be significant changes to the project structure.

[nabla-c0d3]

Thanks!