Remove Swift PM Artifacts to avoid Generated Schemes in Xcode

[hectormatos2011]

All Swift Packages vended by Apple do not currently check in their .swiftpm directories. The .swiftpm directory is an artifact that gets created when a user opens a package within Xcode. By checking in the .swiftpm directory, we risk having a backwards incompatible change in the future affect the auto-generation of .xcschemes in Xcode when adding this package as a dependency in another Xcode project.

Currently, when adding swift-collections as a package dependency within an Xcode project, Xcode uses the .xcscheme files located in the package's .swiftpm/xcode/xcshareddata directory as an indication that it should surface those as schemes within a top level project. This clutters the scheme list for an Xcode project when a user is most likely to prefer only seeing targets/schemes they're actively working on, not dependency targets/schemes.

TL;DR:
This pull request removes the whole .swiftpm directory and adds .swiftpm to the .gitignore list to prevent unneeded xcscheme generation within a top level Xcode project that pulls in swift-collections as a dependency.

Checklist

• I've read the Contribution Guidelines
• My contributions are licensed under the Swift license.
• I've followed the coding style of the rest of the project.
• I've added tests covering all new code paths my change adds to the project (if appropriate).
• I've added benchmarks covering new functionality (if appropriate).
• I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
• I've updated the documentation if necessary.

[lorentey]

Hm; I was relying on these schemes to customize test execution when this package is tested under Xcode. On the other hand, if these schemes are polluting dependent projects, then that seems like a pretty convincing argument for removing them.

Cc @neonichu What's SwiftPM's official guidance here?

[hectormatos2011]

@lorentey I'm so sorry about that! I know how important it is to have an environment that's easy to work with and feels turn key when opening the package. 😢

The good thing about xcschemes is that you can still use them locally on your end as long as you copy the schemes over before pulling from main. Any subsequent uses of it will still stick around since it's in gitignore so you can still have your custom test execution settings!

Also, hi friend @neonichu ❤️

[neonichu]

I don't know of any official guidance for this, but personally, I would not check in any schemes for a package, for the reasons @hectormatos2011 listed.

I think you can create per-user versions of the schemes by unchecking "Shared" which might be a compromise to still getting whatever you need for local development.

[hectormatos2011]

@neonichu you definitely can create per-user schemes. I just tested it on my machine and it sticks around even after git pull. @lorentey if you uncheck "Shared" in the Manage Schemes window, it will store those schemes in a separate folder that won't get deleted after pulling this branch

[lorentey]

Fair enough. Having these schemes show up in dependents is reason enough to remove these. We have a dev workspace in the Utils folder that can hold these schemes just as well, without messing up downstream configurations.

[lorentey]

@swift-ci test

[lorentey]

Slight nit: this is a bit overkill -- I'd much rather have newly created shared schemes show up in git status than having them silently ignored.

(These files aren't litter.)