contextual_preprocess is in every preprocess definition, explore optimizing the map

Pushed a first version of this. Reduces quite a bit of complexity in Registry::build(), $old_cache and addFixedPreprocessFunctions() are just gone.

A little bit of extra complexity in ThemeManager, but that is temporary until support for template_preprocess is removed, then we can just call them between initial and preprocess callbacks.

contextual functional tests are passing with this, might need to adjust some unit or kernel tests.

Tested on our install profile, by printing out echo strlen(serialize($this->registry[$this->theme->getName()])); in \Drupal\Core\Theme\Registry::setCache().

On HEAD, with the preprocess OOP issue: 171994

With this MR: 158078

That's 92%, so about 8% reduction, and also less code complexity, especially long term. The gain is also bigger the more theme hooks and suggestions you have.

Also comparing against just before 📌 Handle module preprocess functions Active was committed, that gives me 164180. So technically, it is also 4% smaller than HEAD was before that but the invoke map will grow again once we also support OOP in themes.

Added a few questions, I could do suggestions for some reason so here is a patch with the changes I was testing.

The reason it's split in and after the loop is because no, template preprocess callbacks are still part of preprocess functions and we need to do run it after those. There is afaik only a single views/contextual integration test that fails if we don't do that, but it's important. That one also failed on my initial attempt in the preprocess OOP issue to split up discovery of global preprocess.

This exactly replicates the logic in the current addFixedPreprocess which this removes, which also inserts them after any template_preprocess function in the list.

What you propose is what we will be able to do once template_preprocess is deprecated and gone, but not before.

We could look into moving template_preprocess into the initial preprocess hook, but with the alter hooks and stuff, I think it's a bit more BC to keep them in there. There are currently also some very weird edge cases with template_preprocess and the base hook key that can result in multiple preprocess callbacks. See the system template preprocess conversion issue.

Removed the unnecessary check for $global_preprocess, it's always an array and check for not already been called first. Also added some more comments, they're a bit repetitive, but it is a bit confusing and maybe that helps understand it.

Note sure if we want to do a change record to call this change out. Again depends on how much we consider the theme registry structure intrernal (which I think we should).

I think this is ready, all of my comments have been addressed and this means work all of the changes the actual registry is smaller than 11.1!