QStandardPaths: some documentation is wrong w.r.t. iOS; other platform inconsistencies

On Android, the first path returned from QStandardPaths::standardLocations() is (planned to be) the system-wide location and the second is the application-specific one. So, the plan was for the QML FileDialog to iterate several of the enum values for general-interest directories, and for each of them, to show the first element returned from standardLocations() as a shortcut, if that directory exists and is visible to the user. But on iOS, the system-wide location doesn't contain readable files, unless a virtual filesystem layer is used so that the application can access certain locations such as the "camera roll". There is no QStandardPaths::CameraRoll, only Pictures, which normally would be the eventual home of pictures after they are imported/organized; on Android that's a different path (/sdcard/DCIM), while on iOS maybe it should identify the virtual filesystem, because there is no shared Pictures directory which is accessible to applications. So it seems the current API doesn't quite fit the situation on sandboxed platforms.

Some of the doc comments which say "the returned path is never empty" should not say that. And we need to be clear about what can really be guaranteed across all the platforms including iOS. It's useful for FileDialog if the first path returned (if any) is the useful one, the one the user should see; while from an API perspective it makes more sense to have the system directory come first and the application-specific one second, or vice-versa, consistently, and to have the docs in sync with that. Or else to have a way to specify which one you want. Applications should ideally not need "if" statements for different platforms to choose different directories.