Don't cache whole extension objects in FileCache

I guess eventually we should deprecate serialisation of Extension objects since storing the app root on them is a bit fraught.

@andypost the file path is part of the cache key so you'll get a miss and rebuild the Extension object. So it bootstrap works just fine.

@daffie #6 just results in never using the cache - because the cache object is an extension object and you're checking if it is an array.

Re-uploading #2.

And this change doesn't really require tests. We use this file cache millions of times during a test run. We're changing what we store in the cache but we're not changing the output of \Drupal\Core\Extension\ExtensionDiscovery::scanDirectory() - if that breaks every thing breaks.

@daffie the answer as to why we shouldn't cache extension objects in the file cache is in the issue summary. We are scanning extension directories very very early in container compilation - that's why we have/need the fallback to DRUPAL_ROOT in \Drupal\Core\Extension\Extension::__wakeup(). We shouldn't fallback to DRUPAL_ROOT - therefore we need to construct new extension objects because they are value objects and we can't and shouldn't add a setter for root on the object. Therefore we need to cache the arguments we use to construct the extension object.

There is one bit of this that is worth testing because it affects real sites. We need to test the ability of ExtensionDiscovery to cope with pre-existing cache entries that have Extension objects and not arrays in them.

There was a random fail

@catch I agree. But for me also #10 misses the point of commenting. The comment in previous patches was in a different place and more relevant. It was:

       $extension_arguments = $this->fileCache ? $this->fileCache->get($fileinfo->getPathName()) : FALSE;
      // Ensure $extension_arguments is an array. Previously, the Extension
      // object was cached and now needs to be replaced with the array.
       if (empty($extension_arguments) || !is_array($extension_arguments)) {

For me this is important because it details that on sites just after this patch is applied the file cache will contain Extension objects and we need to deal with that in a safe way by checking the type. Most cache gets we do don't have a type check because it doesn't often change - though when it does it is often the source of interesting problems.

Backing out #10 as per #15 for the reasons stated.

I disagree with creating another object to represent a partially parsed extension object. Storing the arguments as an array seems fine to me. There's nothing to be gained here for reuse.

What might be possible and interesting to explore whether or not we should use the info parser here and store the parsed yaml instead of reading the file and looking for type: - that way we'd stop reading all the .info.yml twice and if we injected file cache into the info parser then we're speed up cache rebuilds because they'd not have to reparse the extension files.

And I also think it is worth trying to work out out how to remove anything other than extension info from the Extension object.

But this a small step in the right direction that reduces dependency on the DRUPAL_ROOT global.