Use the YAML parsing cache collector for config file storage

OK it works.

We manually create FileStorage objects in a lot of places and many of them won't benefit from a persistent cache or are very unlikely to (module and recipe install for example which usually only happens once per module or recipe).

So for those cases I made it so we automatically create a memory cache-backed cache collector if nothing is passed in, this also means there's no deprecation here except for one factory method.

Installed drush 14 against an Umami site, exported config, then ran drush cim -y with main vs. the MR. Time spent in config sync parsing files goes down from 4s to 100ms. Will be more on sites with more files in the sync storage.

Rebased.

I think I covered all the feedback from @godotislate.

Found #3610503: Optimize StorageCopyTrait::replaceStorageContents() when profiling this one.

Took a quick look at what's likely to conflict, it seems to be mainly the factory changes and it looks to me like it will be straightforward to add this on top of those changes assuming that one lands first.

Rebased.

ConfigImportUitTest failed after the rebase with https://git.drupalcode.org/project/drupal/-/jobs/11210191

 ┐
       ├ Exception: Warning: unserialize(): Class 'Drupal\config_enum_test\EnumValue' not found
       ├ Drupal\Component\Serialization\PhpSerialize::decode()() (Line: 21) 

This happens because the autoloader config wrapper has to read core.extension before it wraps the storage with the autoloader, and if the read of core.extension triggers the cache collector cache read, that gets loaded without the wrapping having happened.

To avoid that, we can exclude core.extension from the cache altogether.

However I think we also need to handle module uninstall here. The MR already has garbage collection, but that's time-based. For now I've added an explicit clear to ModuleInstaller::uninstall() so that the whole cache gets emptied. Module uninstall is relatively uncommon so we'd still get the performance improvement most of the time. It might be possible to go through the cache entry and remove items belonging to a module but that'd be extra logic to worry about.