Add result cache meta extension for DI container

[Wirone]

Important

This feature was brought to you thanks to GetResponse - Marketing Software for Professional Email Marketing, which paid for my work on this.

Fixes #255, continues phpstan/phpstan-src#3765.

---

Following this experiment's results I decided to calculate meta hash based on DI container's actual content (params and services), without interacting with XML file directly. ParameterMapFactory and ServiceMapFactory were used for retrieving data, also I implemented "singleton" approach there, so the XML file won't be processed multiple times (once for calculating hash, then for processing rules).

I start with a draft PR so I can get early feedback. I also need help when it comes to testing this, because I don't see e2e approach here. I wanted to test it on our codebase, but it's really cumbersome to setup Composer dependencies to get dev version of PHPStan and the plugin 😅.

[Wirone]

@ondrejmirtes did you have opportunity to look at it? I hope for your feedback as in the main extension point PR, so I can finish this properly 🙂.

[ondrejmirtes]

It's a bit crazy to urge me less than 24h after you opened the PR. Please avoid that next time.

A literally wasn't in front of my computer since then.

[Wirone]

Sorry, I just didn't know you were notified about the PR because I realised I did not mention you in the description 😅. Sorry for bothering, take your time of course, just wanted to know if you're aware about this one.

[ondrejmirtes]

You can test this by:

1. Create SymfonyContainerResultCacheMetaExtension extends PHPStanTestCase
2. Create a new .neon file under tests/ and link to an actual dumped container XML file which you're going to commit in this repository under tests/.
3. Override getAdditionalConfigFiles method and supply path to the .neon file from 2)
4. Create new SymfonyContainerResultCacheMetaExtension and supply constructor arguments via self::getContainer()->getByType()

[Wirone]

@ondrejmirtes please make sure you're familiar with the commits' messages, as I provided additional info there. When it comes to serialize() I believe it's more stable than var_export() when it comes to producing string that is used for calculating hash. We could use json_encode() too, but it would require adding ext-json to Composer's dependencies.

Again, thank you very much for providing feedback and guiding about tests 🍻.

[Wirone]

To be honest, I am not sure whether services' tags should be taken into consideration when calculating container's hash 🤔. Symfony\Component\DependencyInjection\ContainerInterface and even Symfony\Component\DependencyInjection\Container doesn't expose any API for interacting with tags, these are rather used in compiler passes during container build. But since PHPStan\Symfony\ServiceDefinition contains tags, I included them in the calculation. Let me know what you think @ondrejmirtes 🙂.