[11.x] Skip object construction if no rebound callbacks are set

[axlon]

Something I noticed while debugging #53501 is that Laravel's container currently always instantiates an extended/rebound class to pass to rebinding callbacks, even when no such callbacks are set. This PR fixes that.

[axlon]

I had to adjust a test that specifically tests this behavior, but I think the test was faulty to begin with. The test tested that the container would call a resolving callback when a rebind happened, the only reason the binding was being resolved was because the framework was preparing to call rebind callbacks (which weren't set in the test).

Now the tests properly reflect (what I believe to be) the correct behavior, if a binding is rebound and rebinding callbacks are set the new binding is resolved (triggering resolving callbacks) and the rebinding callbacks are called. If a binding is rebound and no rebinding callbacks are set, the binding won't be resolved and thus the container won't call any resolving callbacks

[taylorotwell]

Could there be a situation where a deferred service provider registers a binding and rebound callback. The developer rebinds a binding that is defined in that deferred provider but that hasn't actually been "made" yet - this PR would make it so the rebound callback defined in that deferred provider would not fire.

[axlon]

This is indeed a problem, I see the Application class already has some logic in place to deal with this in Application::make() and Application::resolve(). This logic should probably be extended to methods that cause rebinds as well if we go this way. I will take a look at this, as well as some tests to cover this

@taylorotwell I added Application::extend() to load any relevant deferred service providers when extending (See 17b04b5), but then noticed a test (FoundationApplicationTest::testDeferredServicesAreLazilyInitialized) started failing.

I think it makes sense to keep extension logic as is. So that no deferred providers are loaded, this is because when an extension is registered the service in question either is, or isn't already loaded. If it is, then the deferrable provider should already have been loaded as well meaning the rebind callbacks must already be present. If it isn't, then there's no need to call any rebind callbacks, because any services that rely on the service being extended could not have been resolved yet either.

[taylorotwell]

I'm not sure, I still think this is breaking. If I have a test and I bind an instance in the container of SomeInterface, and the deferred provider registers a rebind callback that calls a method on things that implement that interface anytime they are bound, that will no longer be called after this PR, which is a behavior change on a patch release.