[flutter_plugin_tool] Refactor createFakePlugin

[stuartmorgan]

createFakePlugin is used extensively in tests, but has become more and more complex over time. This substantially refactors it and related test utilities:

• Extracts a createFakePackage for the cases where we want non-plugin packages (allowing the removal of isFlutter from createFakePlugin).
• Makes most things created automatically instead of being opt-in, so that tests are operating on things that look more like actual packages/plugins unless they specifically override that behavior:
  • Version is added by default.
  • An example/ directory is added by default.
  • A CHANGELOG is added (it can be deleted manually if we ever need to test for that).
• Combines the two different ways of defining the example format.
• Replaces the list of platform boolean with a map of platform name to details. This allows more control over how things are set in the pubspec (currently, federated vs inline), rather than requiring rewriting the pubspec after creation.
• Uses the platform constants in more places instead of raw strings, and renames them to reflect the more general use.
• Eliminates almost all calls to createFakePubspec, as it is almost never needed any more.

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]

A lot of these changes are pretty mechanical. utils.dart is where most of the interesting changes are.

[gaaclarke]

nit: it would be a bit more concise if this was just a list of strings that are paths, then we replaced the '/' with platform specific characters. No need to address it here, just calling it out.

<String>[
        'example/test_driver/integration_test.dart',
        'example/integration_test/bar_test.dart',
        ...

[stuartmorgan]

I think that may actually already work by accident, but I'll look at formalizing it. I agree the current system is needlessly messy.

[gaaclarke]

nit: Instead of manipulating strings, we could create the datastructure then use a yaml library to generate the yaml. That would make this a bit more maintainable.

[stuartmorgan]

Yes, I've thought about that as well. Initial investigation turned up mostly libraries that can read YAML, unfortunately, rather than write it, but I'd like to look into it more at some point.

[gaaclarke]

lgtm, it was a lot to look at. I just had a few nits.