[5.5] More consistent PSR-11 implementation

[RemiCollin]

This modify the behavior of the container has() method to return true if a class that has not been explicitly bound to the container can still be resolved by it.

PSR-11 doesn't impose an explicit binding of concrete class beforehand, so we can consider returning true for any concrete class that can be actually resolved as it's a better reflection of how laravel's container works internally.

See discussion in laravel internals : laravel/ideas#803

[taylorotwell]

So with this change how do you tell if a custom implementation was bound in the container or it is just going to use the default? Also, just because a class is concrete doesn't mean the Laravel container can resolve it. What if it has an interface dependency that isn't configured?

[RemiCollin]

So with this change how do you tell if a custom implementation was bound in the container or it is just going to use the default?

I think that would be the role of the bound() method().

Also, just because a class is concrete doesn't mean the Laravel container can resolve it. What if it has an interface dependency that isn't configured?

Having an abstract bound to a concrete class doesn't guarantee that Laravel container can resolve it as well.

In that regard, the isResolvable() method is misnamed, isConcrete() would be more correct, I guess.