Drop swift-collections dependency to workaround issues for macCatalyst adopters

[simonjbeaumont]

Motivation

Archiving an app for Mac Catalyst fails with a build collision when this package (as a build-tool plugin) and swift-openapi-urlsession are both in the dependency graph (#921):

error: Multiple commands produce '.../UninstalledProducts/macosx/InternalCollectionsUtilities.o'

This is because swift-collections enters the build graph via two independent paths: runtime (URLSession transport) and host (build plugin).

During xcodebuild archive for Mac Catalyst the app compiles both app and build tool for macOS and uses the same UninstalledProducts/macosx/ path, which produces the collision. iOS archives are fine because the runtime and host are different platforms.

The underlying failure to de-duplicate a package shared between the host-tool graph and the product graph is a build-system limitation we can't fix here -- probably needs an Xcode or SwiftPM issue filing.

However, since we've seen this a few times now from different adopters we might be able to mitigate the issue because swift-collections is hardly used by the generator.

Modifications

• Replaced OrderedSet<EnumCase> with a plain [EnumCase] plus a Set<EnumCaseID> membership check, preserving first-seen ordering and the duplicate-value diagnostic.
• Removed the now-unused Equatable/Hashable conformances on EnumCase (they existed only to satisfy OrderedSet).
• Dropped the swift-collections package dependency.

Result

• swift-openapi-generator no longer depends on swift-collections.
• No change to generated code.
• Apps that use the build-tool plugin alongside swift-openapi-urlsession can archive for Mac Catalyst.
• Resolves Xcodebuild archive fails on Mac Catalyst: Multiple commands produce InternalCollectionsUtilities.o #921, Build-tool plugin breaks swift-collections module resolution during xcodebuild archive #890.

Test Plan

• Existing tests all pass.
• Can repro this with xcodebuild archive on the HelloWorldiOSClientAppExample project.