[path_provider] Completely rethink the path_provider API

[stuartmorgan]

The API for path_provider has a number of significant issues:

• It was design before federation existed, so platform-specific paths (like getExternalCacheDirectories, which is highly Android-specific in practice) are mixed in with abstractions in the app-facing API.
• Some of the APIs were designed for Android APIs that have since been deprecated, and the underlying implementation changed, creating some confusing naming.
• The APIs are almost all pre-desktop, so tend to be mobile-centric.
• The desktop implementation of the documents directory (a widely-used API) is, essentially, wrong, and we can't fix it without a breaking change.

The package's API would benefit from being redesigned from scratch. We should:

• Audit all of the existing APIs and open requests for new APIs.
• Make a matrix of all the APIs that it makes sense to support, and what platforms they make sense on.
• Decide what high-level abstractions we want core functionality for (in particular taking a look at the user-created vs. app-created-but-expensive vs app-created-and-easily purgeable, which we have as distinctions right now but in a somewhat platform-fragmented way, and not well named as abstractions).
• Create a two-tiered API system, with common abstractions in path_provider and platform-specific things in path_provider_*, with clear docs in the app-facing package about the existence of the latter, with links to implementation package readmes as examples.

Removing APIs from path_provider would be extremely disruptive as it's such a foundational plugin in the package ecosystem, but we can deprecate the old APIs and create a clean set of new APIs, like we did with url_launcher. That way we don't have to do it as a breaking change, so everyone in the ecosystem can switch to the new APIs gradually, without creating a lot of transitive version conflict problems.