Fix opening projects in Xcode via .xcworkspace or .xcodeproj

[riteshhgupta]

Summary

• Resolve Xcode open actions to a discovered .xcworkspace or .xcodeproj inside the selected directory.
• Prefer .xcworkspace over .xcodeproj, while falling back to the selected directory when no project bundle is found.
• Keep the scan deterministic and bounded, skipping common build/cache/vendor directories such as .build, .swiftpm, DerivedData, Pods, node_modules, and related mobile development sidecar folders.

Why

• Most IDE open actions work correctly when Supacode passes the selected directory as-is. Xcode is different: it expects to open an .xcodeproj or .xcworkspace bundle to load the real project configuration, schemes, targets, and workspace package state.
• Before this change, Supacode treated Xcode like the other editor actions and opened the folder directly. That could leave Xcode showing a generic folder view or miss the intended project entirely, especially when the project bundle lives below the selected root.
• This makes the Xcode action behave like "open this Xcode project" when a clear bundle is present, while preserving the existing folder fallback for directories that do not contain an Xcode project.

Code changes

• Keep Xcode in the existing grouped NSWorkspace.shared.open path used by other apps.
• Add an Xcode-only targetURL override before opening the app.
• Add XcodeProjectLocator to scan the selected directory for .xcworkspace or .xcodeproj bundles, preferring workspaces when both exist.
• Bound the scan depth and skip common generated/vendor directories so the lookup stays predictable.

Before

After

[sbertix]

Thanks 👍
Same as #417, though. Can we make it so the behavior can be generalized (e.g., with an optional computed OpenTarget for app that can pass things as .workingDirectory or .recursiveSearch(/* regex */, excluding: [/* the list of folders to exclude */]), instead of tied to a specific app?

[sbertix]

Could you check if the generalization in #423 still works for you? It worked fine on my devices, but I just wanted to double-check. Apologies for this, but together with #417, it made sense to just tackle them at once with a more coordinated effort.