Repository: flutter
Issue: Consider removing platform support from package examples
Labels: team,tool,package,c: proposal,team-tool

Currently almost all of our packages have example apps that support whatever set of platform were standard when the example was created. Our examples serve a number of purposes that I'm aware of:
1. Demonstrate how to use the the package (e.g., `main.dart` being displayed on the pub.dev page)
2. Serve as a source for README code excerpts in many packages.
3. Run integration tests in CI.
4. Run native plugin unit tests in CI (for most platforms).
5. Allow people to run the package locally to try it out (either for evaluation, or for package developement).

Usages 1&2 don't require the platform support, just the Dart code. 3&4 definitely require the example app to be checked in, but only apply to a subset of packages (~all plugins need it, but very few of our non-plugin packages have integration tests). 5 can apply to any package, but is unlikely to be a common use case.

Keeping a lot of boilerplate platform support code around just for case 5 isn't necessary worthwhile. We could instead, for apps that don't have tests requiring `example`, remove all the platform directories, and just put a README in the example directory saying to run `flutter create --platforms=<foo> .` locally. That step is quite fast, so this wouldn't be much of a burden.

Pros:
- Less maintenance overhead. There is a small but non-zero cost to every incremental platform directory we have, in the form of things like dependabot PRs or automigrations we need to periodically check in to avoid local clutter.
- Less CI overhead. We currently build every example that we find in CI, to make sure they stay buildable. (As of writing, this would only apply to the auto-roller and changes to repo-wide things like tooling or CI config, since PRs that touch only touch individual packages only target those packages in CI.)
- Smaller package downloads. Every client downloads the whole package, including everything in `example/`.
- Consistency across platform. We would avoid things like having packages that have no `example/windows/` only because the package predates Windows being a `create`-supported platform. (Of course we could fix this with a one-time `create` pass over the repo.)

Cons:
- More complexity in running an example locally: someone doing this would need to figure out that they need to do this and/or find the docs saying they need to do this.
- Inconsistency across packages. Packages with integration tests would have examples, others wouldn't, so anyone running multiple package examples (e.g., Flutter team members) may find it confusing.
- Stale local platform dirs. People interacting with the repo over a long period would sometimes run into breakage that they wouldn't now, and need to know to regenerate the local app. E.g., currently if I run an package on Android once, then again a year later in an updated copy of the repo, it'll likely work because updates will have been checked in. But in this scenario, I'd have a year-old `android/` directory that is likely to have become outdated.
- No way to indicate explicit platform support choices. For example, there's a reason that `xdg_directories` only has a `linux` directory in its example.
- Some complexity around things like internet access entitlements. @jmagman pointed out that we can leave just those files that need to be edit, so things would Just Work. The caveat is that it may confuse people, or even tooling, to have the directory there but not be complete.