[file_selector] Add macOS support

[stuartmorgan-g]

Brings file_selector_macos into flutter/plugins from FDE, with the following changes:

• Refactored slightly to allow for unit tests of almost all of the native code
• Added native unit test coverage
• Translated to Swift, to follow repo conventions for macOS plugins
• Added an in-package example (almost an exact duplicate of the app-facing version, but written against the platform interface, as is our current practice)
• Moved to an in-package method channel. As part of that, moved the flattening of type groups from Swift to Dart.

Does not currently include native UI tests to allow for end-to-end testing (since Flutter integration tests can't be used). They should be added later (they are currently blocked on flutter/flutter#90673), but the unit tests give substantial coverage, making it substantially better to move the plugin now to get those tests running.

macOS portion of flutter/flutter#70221

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
• All existing and new tests are passing.

[stuartmorgan-g]

@cbracken There are two options for review here:

1. As a full review
2. As diffs from what's in FDE, using the incremental commits

2 is complicated somewhat by the fact that after I had the unit tests in place I translated the plugin to Swift, but that's its own commit so it can be done as a side-by-side.

Either way:

• You can pretty much ignore example/lib/ unless you have a strong desire to review it, because it's just a clone of file_selector/file_selector/example/lib/ with very minor changes to use a different interface (something we're trying to figure out a good solution for in federated plugins in general, but don't currently have).
• All of example/macos/ is just boilerplate flutter create, other than the unit test file (and the addition of a unit test target)

[ditman]

(Maybe some day :P)

[Hixie]

What's the status of this PR?

[stuartmorgan-g]

What's the status of this PR?

Waiting for @cbracken to have time to review it.

[cbracken]

See comments on the Windows patch for the example.

[stuartmorgan-g]

@cbracken This is ready for review:

• I updated the example to match the Windows changes
• I added the in-package method channel
• I reworked the native code and tests to put a stub-able protocol between the plugin implementation and the FlutterPluginRegistrar because it turns out we can't always support both master and stable with direct stubs. Master added a new method that uses a new type recently, and a stub would have to implement that method... but can't because the type of one of its arguments doesn't exist on stable. (And more generally, we'd be broken any time a new method were added to FlutterPluginRegistrar, and would have to update the tests, which isn't great.)

[cbracken]

lgtm just two minuscule nits.

[cbracken]

pedantic nit: s/ then/then/

[stuartmorgan-g]

Done.

[cbracken]

Move comment a few lines down.

[stuartmorgan-g]

🤦🏻

[stuartmorgan-g]

For some reason I'm not able to add labels to this PR at the moment, so landing manually.