Revert "Support for psr/container v2"

[Ocramius]

Reverts #127

As found in multiple downstream containers, the lack of a constraint on psr/container:^1 led to upgrades that are completely incompatible with psr/container:^2 signatures.

The problem is that child classes have methods without a : bool return type declaration for ContainerInterface#has(string $name): bool, which means that a fatal error is raised, due to LSP compatibility checks performed by PHP.

Practically, upgrading to psr/container:^2 may really happen in a major version, possibly as an isolated dependency upgrade.

While @boesing has worked hard in trying to implement a BC-compliant solution, the SAT solver of composer will find a way to upgrade to incompatible dependencies anyway, and inheritance is such a massive headache that we may really just want to get rid of it overall, rather than

Ref: laminas/laminas-hydrator#92
Ref: laminas/laminas-di#78
Ref: #146

[boesing]

Simple revert. I don't see a better solution tho.
We should think about closing our implementations while providing proper interfaces to allow composition.

IMHO, v4 should have final ServiceManager and the plugin manager should not implement PSR-11 anymore.
If the plugin manager is as configurable as possible, we might not even need an abstract plugin manager.

[Ocramius]

Can't wait myself for final on the ServiceManager :D

[Seldaek]

Due to 3.15.0 existing with psr/container 2 support it means I am now stuck on that version as I have other things requiring psr/container ^2.

I don't think it matters much given the fairly small usage of laminas components I have in the project, but just wanted to let you know that you may be protecting some users from bad upgrades (tho really they can easily pin psr/container:^1 themselves if their code requires it to function) but it is also causing issues for other users that are ready to update.