Permission handling API

Many features of today's devices and operating systems can have significant privacy, security, and performance implications, if misused. As a result, it's increasingly common for platforms to require explicit consent from the user before accessing these features.

In Qt 6.5 we established a generic, plug-in based framework, adding an initial set of API and platform support.

For 6.6 we're planning QML APIs, and a few additional permission tweaks (see linked issues).

Brainstorming during initial 6.5 developement:

• How to model read-only and other common variants of permissions
  • QPermissions::PermissionModifier enum and dedicated PermissionRequest type allowing e.g. requestPermission(Calendar | ReadOnly)
• How to model more complex permissions such as location accuracy
  • Via QPermissions::LocationPermission subclass with dedicated setters for accuracy and availability
• What to name the permission results (Denied/Rejected/etc, Accepted/Authorized/Granted, etc)
  • Renamed Authorized -> Granted, based on: 
    • Apple: Authorized/Denied/NotDetermined (but some callbacks take a "granted" bool parameter)
    • Android: Granted/Denied
    • Web: Granted/Denied/Prompt
    • Windows: Allowed/Denied/UserPrompt
• Whether to allow calling checkPermission from secondary threads (requestPermission is main thread only)
• Whether to adopt a combination of the defaults discussed in an earlier comment, where QT_CONFIG is combined with Undetermined
  • Adopted QT_CONFIG based approach as discussed in comment-662003
• Whether the API belongs in QGuiApplication since it potentially depends on user interaction to request permissions. 
  • Permissions can be requested for QCoreApplication cases as well, at least on some platforms (macOS), for example for recording audio, or reading contacts. The permission UI is presented by the system, so it doesn't matter that the app itself is running headless.
• Determine whether Restricted is needed
  • Will remove. There is very little use-case for distinguishing between being  denied a permission because the user clicked "deny" in a dialog or because the user enabled restrictions on that permission globally. This approach is also what Chromium seems to do: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/device/bluetooth/bluetooth_adapter_mac.mm#228
• Determine whether libraries should request permissions on behalf of users, or limit to checkPermission
• Whether the API should go into QCoreApplication or the QPermissions namespace
  • Decided on QCoreApplication, as that leaves us a place to have possible signals in the future
• Whether we need a static API or not
  • No need for static API, as requiring a QCA instance is fine, and aligns with the best-practice of requesting permissions late (when needed), instead of first thing in main()
• Additional permissions
  • BodySensors
  • PhysicalActivity
  • Storage
  • Notifications
  • ScreenCapture
  • Reminders
  • Photos