Reconsider manifest check logic for Bundler and SPM

Below is a verbatim copy of my comment on WordPress iOS, https://github.com/wordpress-mobile/WordPress-iOS/pull/22525#issuecomment-1928592156, describing the issue.

---

`@iangmaia` I believe the Danger comment (the 2nd version, in case it changes in the future after new commits), https://github.com/wordpress-mobile/WordPress-iOS/pull/22525#issuecomment-1922301618 ,about the `Package.resolved` is out of place 🤔


I think we might have been too optimistic in implementing the `Package.swift` `Package.resolve` check. 🤔 CocoaPods tracks an hash of the `Podfile` content in `Podfile.lock`, so any change to `Podfile` generates a changes in `Podfile.lock`. But Bundler and SPM don't do this.

I don't know how to go about "fixing" the behavior, because one would have to parse the change itself. E.g. if `Gemfile` changed with only comments, do not expect `Gemfile.lock` to change. If a new gem was added, expect it to change.

To make matter worse... The modules package currently defines no dependencies and therefore has no matching `Package.resolved`!

One idea to start with would be to simply relax the warning. Something like, from:

> `Modules/Package.swift` was changed without updating its corresponding `Package.resolved`. Please resolve the Swift packages in Xcode.

to:

> `Modules/Package.swift` was changed but its corresponding `Package.resolved` was not updated. Make sure you resolved the Swift packages in Xcode. If you have done so already, you can disregard this warning.

Review the existing manifest checks involving Gemfile/Gemfile.lock and Package.swift/Package.resolved, then use the linked WordPress iOS comment for the reported behavior. Done means the Bundler and SPM warnings no longer assume every manifest change requires a lockfile update, while still communicating what contributors should verify.

Written by the indexing model from the issue text.