Fix and document the Swift Package Manager section of the main README

[Pachebel]

The "iOS - Swift Package Manager" section of permission_handler/README.md is where most users
will look, but it no longer covers what the package does. This brings it up to date and points to
the permission_handler_apple README for the full detail, rather than duplicating documentation
that would drift. It also fixes a small factual error the same audit turned up in the
permission_handler_apple README itself.

Follow-up to #1554, as discussed there.

Corrections

The Info.plist key table was wrong in four places. Checked against the plistKeys of each macro
in Package.swift:

Permission group	Was	Now
calendarWriteOnly / calendarFullAccess	listed as two separate keys on two separate rows	one row — both keys map to the same macro, PERMISSION_EVENTS_FULL_ACCESS, and either enables both
photos	NSPhotoLibraryUsageDescription only	also NSPhotoLibraryAddUsageDescription
location	NSLocationWhenInUseUsageDescription only, shared a row with locationWhenInUse	also NSLocationAlwaysAndWhenInUseUsageDescription; locationWhenInUse now has its own row, since PERMISSION_LOCATION_WHENINUSE is a separate macro with a narrower key set
bluetooth	NSBluetoothAlwaysUsageDescription only	also NSBluetoothPeripheralUsageDescription

The section also claimed "no additional configuration file is needed", which stopped being true
with #1554.

Separately, PERMISSION_HANDLER_VERBOSE was documented (in both this README and
permission_handler_apple/README.md) as always logging "the app root". That's only the case
without a permission_handler.yaml; with one, it logs the active flavor instead. Fixed the wording
in both places.

While in there I also found a few gaps in permission_handler_apple/README.md itself — the README
this PR points users to, so it seemed worth closing them in the same pass rather than leaving a
link to documentation with holes in it:

• strict: false was never explained — only strict: true's behaviour was documented.
• select's validation (added in Add opt-in per-flavor permissions for Swift Package Manager builds (2/2) #1554: one build configuration can't belong to two flavors,
  configurations must be a list, flavor names must be strings, strict must be a boolean) had a
  single line covering the first rule and nothing for the other three.
• select --app and --derived-data weren't documented at all, despite being what makes the
  command usable in CI, which is where it's most likely to matter.

Additions

• How plists are located. INFOPLIST_FILE is read from the Xcode project and .xcconfig
  files, and keys are merged across build configurations — worth stating, because the merge is
  what makes the flavors section below necessary.
• Apps with flavors. A short permission_handler.yaml example and the select command, with
  a link to the full per-flavor documentation.
• Builds started from Xcode.app. These run with / as their working directory and cannot be
  detected, so they need PERMISSION_HANDLER_INFO_PLIST. This is a recurring source of issues and
  was not mentioned anywhere in this README.
• Troubleshooting. When discovery fails, every permission is compiled out and all checks report
  denied with no visible error — the failure mode behind [Bug] Automatic permission detection doesn't work in apps using flavors #1548. Since Xcode discards manifest
  output, the block shows the swift package dump-package invocation that surfaces it.
• A pointer to the permission_handler_apple README, which is where the environment variables
  and the per-flavor workflow are documented in full.

No code changes, so no version bump and no CHANGELOG.md entry.

Pre-launch Checklist

• I made sure the project builds.
• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is does not need version changes.
• I updated CHANGELOG.md to add a description of the change, or this PR does not need one — docs-only, no behavior changed.
• I updated/added relevant documentation (doc comments with ///).
• I rebased onto main.
• I added new tests to check the change I am making, or this PR does not need tests.
• I made sure all existing and new tests are passing.
• I ran dart format . and committed any changes.
• I ran flutter analyze and fixed any errors.

[mvanbeusekom]

LGTM! Thank you @Pachebel for also picking this up!