Anticipate AppKernel creation so that cache clear locking is used effectively

[jolelievre]

Prerequisites

• I understand and accept the project's code of conduct.
• I have already searched in existing issues and found no previous report of this bug.

Describe the bug and add attachments

This issue is about improving/fixing the bugs we encountered while the Symfony cache is being cleared.

Here's a list of related issues (but there are probably others):
#28304
#30011

One strategy suggested was to check if the lock file was already blocked before the kernel is even started:
#31419

But it seemed weird that we had to do this for Symfony so in the meantime, an alternative solution was proposed in this PR: (also based on a lock file but custom to PrestaShop:
#31820

Expected solution (we're not sure it is valid, that's why it needs to be tested)

This solution is still not ideal because again we ignore the system from Symfony that is supposed to handle this, so a better solution should be searched in 8.1.x (if we find the time) or 9.0 if the changes are too impactful, here is the idea.

• In admin-dev/index.php the creation of the Kernel should be the very first thing done
• Many operations are handled in config.inc.php they should be moved and handled by the Kernel itself via container pass or listeners
• To avoid a big impact since config.inc.php is also used by the front we can split the files into config.inc.php and admin.config.inc.php to reduce impacts
• Once we manage to make the BO work with this we then need to validate that it is indeed a solution to the related problem (cache clearing and concurrent calls while the container is being built)
• We should check in the cache:clear command from Symfony if the lock file is created early enough so that any concurrent process is blocked as soon as the cache rebuilding starts
• Finally we need to check all the impact this modification can have via our automated tests and functional tests