Add utility to validate Xcode projects' common TestFlight validation issues

[AliSoftware]

A utility like validate_xcode_project_consistency or whatever could be useful to ensure that some common misconfigurations we encountered in the past wouldn't get us rejected during TestFlight upload.

Why?

In particular, tests around the following would be useful, because such situations won't prevent Xcode from building and won't appear as errors during Xcode compilation and in PRs, and will thus only be noticed at the time we try our first upload to TestFlight after such misconfiguration would be introduced.
And when those TestFlight validation errors happen it's sometimes tricky to debug what the root cause is (because the iTMSTransporter / altool errors are not always clear and sometimes even misleading), while those usually happen when we're in a rush to release a new version and thus need to be unblocked quickly; so better detect those ahead of time instead.

What?

• Ensure that all the .app and .appex targets all use the same CFBundleVersion and CFBundleShortVersionString values (see example TestFlight upload/validation rejection here)
• Ensure that none of the app icons (*.xcassets/*.appiconset/*.png) have an alpha channel (see this Tumblr iOS script for inspiration
• Ensure that the final generated .app bundle doesn't contain nested frameworks, to avoid the issues described in paNNhX-ee-p2. We could use some inspiration from this script, or simply just use find {path-to-final-app} -path '*/Frameworks/**/Frameworks/*' to detect those in the final .app, and print some guidance in the error message to suggest to use "Do Not Embed" setting on the dependent frameworks of the offending target(s).

Alternatives Considered

This sort of check could alternatively be better suited to be implemented by a fastlane action? (either in our release-toolkit, or even better, by contributing to fastlane's core repo to add such checks… either as a separate action, or as a final set of checks that would be run at the end of the gym/build_app action (opt-in via some ConfigItem, maybe?)