Add Composer Caching about .github

[dlh01]

I'd like to suggest some reasons why caching shouldn't be a part of the workflows in this repo and that, instead, individual repos be encouraged to include caching if they'd find it helpful.

Adding caching adds a new way that a workflow can break. Granted, most of my experience with dependency caching and CI workflows come from our private client repositories. But in that experience, when a workflow breaks because of something related to cache, it's usually not easy to figure out why, not easy to replicate the problem locally, and not related to the changes in the Pull Request. Implementing the catch-all solution of "clear the cache and try again" is, arguably, also a barrier for someone who doesn't know how to do that (or doesn't have the permission to). All of these conditions make the problem frustrating for someone who is put in a position where they don't have control over why their PR appears to be failing automated tests, especially if they haven't seen Composer caching before.

So, my sense is that omitting caching generally makes it easier for any developer to simulate the behavior of the workflow, which in turn makes it easier to contribute.

Even our busiest repos aren't getting a ton of PRs every month — at least not yet. Are we going to be saving that much time by caching in exchange for its added complexity? Maybe, but I'm not sure.

[srtfisher]

@dlh01 totally agree. it's probably a small amount of time saved. it could also be something optional for the workflows that people can opt into (versus on by default).

[dlh01]

Making it available but opt-in would be a great balance!