Optimize batchable cache calls for cached queries

[maca88]

This PR tends to minimize 2nd level cache calls when retrieving entities/collections from the batchable cache when assembling objects from a cached query. Today, when a cached query is retrieved from the cache the same batching logic is applied as when a lazy entity is initialized, which means that the entity batch fetch size will be used that can be far less that the query result count. To solve this problem a special queue was created that is initialized by the query cache and will replace the current one in order to optimize the cache calls. Once the query cache is done with the assembling the special queue is removed and the old one takes its place.
There is still one optimization that can be done but would require to have the CacheBatcher on a sesssion in order to combine multiple entity/collection batch loads when they are not present in the cache. Additionaly a special setting could be added that would allow to batch a bigger number of entities when batching from the database entities that are present in the cached query.

This PR should be reviewed after #1952

[maca88]

Rebased.

[maca88]

I forgot to re-run the async generator for the last commit, should we create a PR to fix that or do a force push on the last commit in the master?

[fredericDelaporte]

Force pushes are not allowed on master. (I could lift the restriction but I would not do it. On patch branches I may allow myself to lift it for dropping more serious mishap.)

For merged async regeneration lacks, the handling varies. When it has no impact on the feature (like namespace or test only changes), we tend to just let some later PR fix it with its own async regeneration. When it has an impact on the feature, better do a separate fix.

So I have done #2063.