fix: keep dumped container cache correct across relocation, upgrades and inline classes (fixes #690)

[dgafka]

Why is this change proposed?

• A dumped container keeps the absolute cache directory of the machine that built it. Deployments that warm the cache on one host and run the artifact from another path fail as soon as a gateway proxy is generated lazily ([Symfony] Relocated compiled container keeps the build-time cache path #690).
• The installed-dependency lock file never reached the cache key — the path was concatenated without a separator, so the file was never found. Upgrading Ecotone leaves the previous container in place.
• The cache key records which files a configuration registered, not which classes. Two configurations declared in the same file share one cache entry, so a container built for the first is served to the second.
• Anonymous classes cannot be addressed by a dumped container at all: their name embeds a counter that changes between processes, so a configuration built from one can never resolve from cache.

Description of Changes

• Loading a cached container now supplies the runtime cache configuration to it, so services resolve paths from where the container runs rather than where it was built.
• The cache key now covers the installed-dependency lock file and the names of registered classes, not only their file contents.
• Configurations registering an anonymous class no longer cache and are rebuilt each time. This is silent — caching is an optimisation, and raising here would break suites passing useCachedVersion: true alongside inline handlers.
• Tests added for each: a relocated container in the Symfony bundle, plus cache-key and bootstrap-isolation tests in core. Each was confirmed failing before the fix.

Verified: Ecotone 1318 tests green, PHPStan clean, php-cs-fixer clean, Symfony/Laravel/Tempest suites green.

Pull Request Contribution Terms

• I have read and agree to the contribution terms outlined in CONTRIBUTING.