iOS updates: output filters, requirements installation, docs

[freakboy3742]

As part of fixing beeware/Python-Apple-support#176, it has been necessary to switch to using .dylib extensions for binary extension modules on iOS. As a result, the Briefcase log filter no longer sees those output lines.

This PR:

• Modifies the log filter to include .dylib extensions on iOS.
• Modifies the dependency installation process on iOS to do 2 passes, one for device, and one for simulator.
• Updates the Android publication docs to reflect recent changes
• Adds iOS publication docs
• Updates the FAQ, iOS and Android docs to provide details about binary wheels on the platform pages.

Testing these changes requires:

• An updated iOS Xcode template: Process library binaries into the Frameworks folder. briefcase-iOS-Xcode-template#23
• An update iOS support package build: Switch to using .dylib format for iOS binary modules Python-Apple-support#187
• (optionally, but ideally) updated builds of some third-party binary wheels. See https://github.com/beeware/mobile-forge

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

• An updated iOS Xcode template: Process library binaries into the Frameworks folder. briefcase-iOS-Xcode-template#23

CI is currently blocked by a merge failure, but previously it was failing because it needed the template update. Didn't we come up with some way to mark a Briefcase PR and a template PR as being linked so CI would test them together?

[freakboy3742]

• An updated iOS Xcode template: Process library binaries into the Frameworks folder. briefcase-iOS-Xcode-template#23

CI is currently blocked by a merge failure, but previously it was failing because it needed the template update. Didn't we come up with some way to mark a Briefcase PR and a template PR as being linked so CI would test them together?

It's difficult to do this for Briefcase CI tests because there are multiple templates - the base briefcase template, then one for each platform. However, the reverse arrangement does exist for templates, which is what the Xcode template has defined. The theory is that we can run the template against a branch of Briefcase, confirm that the template works with the current state of a specific Briefcase PR, merge the template PR on that basis, then re-run CI on briefcase against the now "dev" template as a final re-confirmation.