Move `xcodeproj` folder away from the project root

When called in the root of the project `xcodebuild -resolvePackageDependencies` will generate `Package.resolved` in both the `xcodeproj` and `xcworkspace` folders. This is likely a bug, as the same command with the 16.0 beta 3 version only generates the resolved file in the `xcodeproj` folder.

Regardless of the cause, this behavior can, sometimes, result in CI failures such as the one in this build: https://buildkite.com/automattic/pocket-casts-ios/builds/7634#019113ca-d4bd-4838-b93a-aae0e4a0528f

```
an out-of-date resolved file was detected at /opt/ci/builds/builder/automattic/pocket-casts-ios/podcasts.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved, which is not allowed when automatic dependency resolution is disabled; please make sure to update the file to reflect the changes in dependencies. Running resolver because requirements have changed.
```

One solution is to specify the workspace to the command. See how this build passes: https://buildkite.com/automattic/pocket-casts-ios/builds/7657

```
xcodebuild -resolvePackageDependencies \
-workspace podcasts.xcworkspace \
-scheme pocketcasts
```

While this approach does the job, it requires us to drop the SPM caching because the [`install_swift_dependencies` command in the CI toolkit](https://github.com/Automattic/a8c-ci-toolkit-buildkite-plugin/blob/508239432aedbf47eda1f194860ac9db30e237a4/bin/install_swiftpm_dependencies#L43) does not support those options.

Of course, we could add support at the toolkit level, but there is an alternative approach.

A different approach would be to move the `xcodeproj` in a subfolder. This is the setup used in WordPress and WooCommerce, for example.

I find this approach attractive because it would give us a chance to tidy up the project root folder. For example, we could use this structure:

```
Modules/ # already exists and contains Swift packages
Targets/ # would contain the sources for the various targets - each target could have its set of xcconfig
Xcode/
Config/
Project.base.xcconfig
Project.debug.xcconfig
# etc
podcasts.xcodeproj/
# all the other files that stay in the root
```

@Automattic/apps-infrastructure what do you think? Is it worth establishing a convention of moving the `xcodeproj` folder away from the root if an `xcworskpace` is in use? Or should we take this as the occasion to make the `install_swift_dependencies` CI toolkit plugin more flexible?

Of course, nothing stops us from doing _both_, but give each approach would make the other unnecessary, I'd rather take a choice on which one to focus on in the short term.

Start by reviewing the project-root layout and the `install_swift_dependencies` command in the linked CI toolkit, then compare the two Buildkite examples and their `xcodebuild` invocations. The issue is complete only after the team chooses and implements either the project reorganization or the CI-toolkit change, with dependency resolution and CI caching working without duplicate or out-of-date `Package.resolved` files.

Written by the indexing model from the issue text.