Refactor: Separate AutoInject from SetContainer build callback

[asdqwe02]

• Move RegisterBuildCallback(SetContainer) to start of InstallTo.
• Separate AutoInjectAll from SetContainer and add to container build callback at the end of InstallTo

Currently, SetContainer is registered as a build callback before InstallTo is called and AutoInjectAll is call inside SetContainer, meaning user-defined container build callbacks will be called after MonoBehaviours are auto-injected via LifetimeScope.

This change separate AutoInjectAll from SetContainer and add builder.RegisterBuildCallback(AutoInjectAll) to the end of InstallTo, ensuring it is always the last registered build callback. As a result, when MonoBehaviours are auto-injected via LifetimeScope, all container build callbacks (including any registered by user installers) are guaranteed to have completed first.

Before: SetContainer (with AutoInjectAll) callback was registered before InstallTo, so it could be invoked before user-defined callbacks.
After: AutoInjectAll is separated from SetContainer, add AutoInjectAll as last container build callback so it runs after all other build callbacks have finished.

[vercel]

@asdqwe02 is attempting to deploy a commit to the hadashia's projects Team on Vercel.

A member of the Team first needs to authorize it.

[asdqwe02]

@hadashiA hey sorry for the tag but if possible can you check this pull request? I understand it sound like a minor issue but I think updating it could help other who have issues with container built callback being called after AutoInject is run
(I have this case happened before in my project when I wrote extra logic that run during after container is built but need them to run before AutoInject happened).

[hadashiA]

Hi, thanks for the PR.

First, this is a minor point, but regarding the PR title. This isn't a refactoring. It is a fix accompanied by breaking changes with the intent that "I want to execute AutoInjectAll only after all user-defined build callbacks are completed." Since it also affects existing users, I'd like you to state that clearly in the title and description.

While I think this request makes sense, there seem to be the following issues with the implementation:

• If a user calls RegisterEntryPoint / UseEntryPoints inside Configure (a very common case), the Dispatch callback gets registered at that point.
• In this PR, since the registration of AutoInjectAll is at the end of InstallTo, the order becomes SetContainer -> Dispatch -> AutoInjectAll.
  Since Dispatch synchronously executes IInitializable.Initialize() / IPostInitializable.PostInitialize(), accessing a MonoBehaviour before it gets auto-injected from an entry point will break it.

In the current implementation, AutoInjectAll is always first, so it was guaranteed that "auto-injection is complete when the entry point executes." This PR is a regression that loses that guarantee (when entry points are registered inside Configure).

Presumably, a different mechanism to guarantee the order is needed.