6.x remove league/container - #19559

The previous commit kept a thin Cake\Core\Container subclass and a
Cake\Core\ContainerInterface that added a delegate() requirement on
top of Cake\Container\DefinitionContainerInterface, purely so the
concrete class had something to implement. With only one container
implementation left, that layer added nothing.

- delegate() moved into Cake\Container\DefinitionContainerInterface
  itself (Cake\Container\Container already had a concrete delegate()
  method, just undeclared in its interface and missing a return type).
- Cake\Core\Container and Cake\Core\ContainerInterface are deleted.
  Every services(ContainerInterface $container)/getContainer(): ... /
  bootstrap(ContainerInterface $container) signature across
  ContainerApplicationInterface, PluginInterface, BasePlugin,
  ServiceProvider, ComponentRegistry, ControllerFactory,
  BaseApplication, MiddlewareQueue, CommandFactory,
  EventListenerRegistrationTrait, and ContainerStubTrait now types
  against Cake\Container\DefinitionContainerInterface directly, and
  BaseApplication/WebExceptionRenderer instantiate Cake\Container\
  Container directly instead of a Core-level wrapper.
- ServiceProvider::getContainer() no longer needs its override - it
  was only asserting the container satisfied Cake\Core\
  ContainerInterface, which no longer exists.

Full test suite passes (10,183 tests, same single pre-existing
stdin-availability failure as before); phpcs and phpstan show the
same pre-existing findings as the unmodified baseline on every
touched file.

Now that Cake\Core\ContainerInterface is gone, "DefinitionContainerInterface"
read as an oddly-qualified name for what is simply the container's public
interface. Renamed to Cake\Container\ContainerInterface across the package
and every consumer (Core, Http, Controller, Console, Event, and their tests).

This introduces a name collision with Psr\Container\ContainerInterface in
the three files within the Container package that reference both: the
interface's own file, Container.php, and ArgumentResolverTrait.php. Each
now aliases the PSR import as `PsrContainerInterface` and keeps bare
`ContainerInterface` referring to the local (same-namespace) interface -
except where a method genuinely operates on any PSR-11 container rather
than Cake's own (delegate()'s parameter, defaultToShared()'s return type,
and the has()/get() check in ArgumentResolverTrait::resolveArguments()
that must also match a bare ReflectionContainer, which only implements
the PSR interface), which explicitly use PsrContainerInterface instead.

Full test suite passes (10,183 tests, same pre-existing stdin-availability
failure as before); phpcs and phpstan show identical findings to the
pre-rename baseline on every touched file.

ServiceProvider only ever depended on Cake\Container classes
(AbstractServiceProvider, BootableServiceProviderInterface,
ContainerInterface) - it's a thin CakePHP-flavored convenience layer
over the container package's own service provider base class, not
something that belongs to Core. Moved to Cake\Container\ServiceProvider
alongside it, dropping the now-redundant ContainerInterface import
since it's the same namespace.

Test file and the two TestApp service provider fixtures moved/updated
to match. No composer.json changes needed - cakephp/core already
requires cakephp/container for its other Container-typed interfaces
(ContainerApplicationInterface, PluginInterface, BasePlugin), and
cakephp/container's PSR-4 autoload already covers the new file.

Full test suite passes (10,183 tests, same pre-existing
stdin-availability failure); phpcs clean, phpstan identical to the
pre-move baseline.

Console (CommandFactory), Event (EventListenerRegistrationTrait), Http
(BaseApplication, MiddlewareQueue), and ORM (TableContainer) all
reference Cake\Container\* classes directly, but none of their
composer.json files declared cakephp/container as a dependency - it
only worked because this monorepo autoloads everything from one flat
src/ regardless of which subpackage composer.json declares what.

Caught by split-package static analysis, which installs each
subpackage's own declared dependencies in isolation: phpstan couldn't
resolve Cake\Container\ContainerInterface at all when analyzing Http
standalone, since cakephp/http never required cakephp/container.

`composer stan` runs phpstan, psalm, and structarmed (an architecture
layer linter) across the whole repo - broader coverage than the
scoped checks used while landing each individual commit in this
series, which is how these slipped through:

- ArgumentResolverInterface::resolveArguments()'s docblock declared
  an overly-narrow param type (array<LiteralArgument|ResolvableArgument>)
  that never matched what the method's own implementation actually
  handles (any ArgumentInterface, checked generically via instanceof).
  Adding attribute-resolution support widened the argument list to
  include LiteralArgumentInterface, which is what finally tripped
  phpstan's stricter cross-class analysis. Corrected the docblock to
  the interface both call sites and the implementation actually use.

- structarmed.php's layer ruleset predates this whole
  league/container removal: it only allowed the `Core` layer to
  depend on `Container`, because previously everything else reached
  the container through Core's own Container/ContainerInterface
  wrapper. Now that Console, Controller, Error, Event, Http, and
  TestSuite depend on Cake\Container directly by design, the ruleset
  needed the same layers added to reflect the now-intentional
  architecture instead of the one it's replacing.

- psalm-baseline.xml had two stale entries for
  ComponentRegistry::getContainer()/getMode() left over from earlier
  cleanup in this series; psalm's own baseline pruning removed them
  since they no longer match current code.

Verified with `source setup/env && composer stan` (phpstan, psalm,
and structarmed all clean, exit 0) and the full test suite (10,183
tests, same single pre-existing stdin-availability failure).