Explore performance of config caching per context

Problem

In #1763640: Introduce config context to make original config and different overrides accessible @pounard said:

ConfigFactory::get() caches config objects overriden by specific contextes, but ConfigFactory::leaveContext() does not clear the cache accordingly, this is what I would call a memory leak.

ConfigFactory::get() caches multiple versions of the same config object, isn't it too much in memory? Let's say we have an average of more or less 30 config objects (what I measured some days ago on a fresh D8 install from git) and half of them are being hit in various contextes (language and user for example) would I have N + 1/2N * M config objects into memory (where N is 30 and M the number of contextes my page encounters in my example 2, which leads to a total count of 60). This is a relatively small number, but I guess that once I'd have enabled 60 modules for example, this would lead to a stupidely high number of instances and a lot of data duplication.

In response Gábor Hojtsy said:

For the ConfigFactory::get() "memory leak", the way it currently implemented, if you enter the same context again later, your values are already cached. If we clear out values when leaving contexts, that could lead to performance issues as well. For example, you are in a user context and enter a free context inside then leave that to return to the user context. Then any values previously cached for that user context would need to be fetched again. Is that better?

Same stands for the multiple copies cached in memory problem.

Proposed solution

Figure out if caching more or purging more and possibly doing more lookups is better. This might depend on overrides being used. Eg. single language site, multilingual operations, etc.