Delay Entity Initialization for Spawn Behavior, add addition Container Spawner Methods

[Princess-Cheeseballs]

Description

Exactly as the title says, I delayed the initialization of entities spawned until they have been properly re parented or inserted into a container during spawning behavior.

• Fixes entities raising MapInit and ComponentInit in nullspace causing Transform data to be inaccurate when spawning. This resulted in some content bugs where entities would just not spawn and also a heisentest.
• This also should fix Entities don't get properly woken when being moved from nullspace. #6258 since this was partially caused by entities initializing in nullspace during predicted spawning. Some content spawning methods will need to be altered but this fixes the majority of them.
• This would also allow us to delete Jez's workaround in SolutionsSystem which delays initialization for solutions until they're inserted into their container.

Why?

This was causing bugs on upstream where for example: I spawn an entityA which spawns a random entityB from a table due to its component. EntityA spawns and initializes in nullspace, so when it tries to spawn entityB, entityB fails to spawn.

This was often worked around on content by just writing their own spawn behavior to purposefully delay initialization in very specific edge cases, and does not work with prediction.

This specific example is the cause of a bug with the Crystals Reaction on content, and almost caused a heisentest with the surplus crate, but luckily it was caught before that PR was merged.

The changes to initialization were going to be their own PR, but I ended up recreating one of the methods in this PR in my efforts to de-duplicate code, so I just merged it into this one. Similarly, on content people often just rewrite parts of TrySpawnEntityInContainer for performance reasons so we don't have to keep trying to get the same container over and over again so moving that boilerplate to engine is probably for the best.

Breaking Changes

When spawning entities MapInit is not run until the entity has been reparented to its final parent.

[slarticodefast]

Please add documentation to all the new methods, container code is already confusing enough 😄

[Princess-Cheeseballs]

Updated PR description since it now makes some decently sizable changes to spawning behavior in an effort to fix spawning bugs on content.

[moonheart08]

This makes uninitialized entities observable in content via the container events. Containers do a lot of things to entities as well so for example if you used these methods on a newly spawned wall, containers themselves would observe the uninitialized state by failing to unanchor it.

I'm not sure this approach is workable, deferring mapinit alone would need reviewing most mapinit implementations in content to make sure they're ready for the change.

[Princess-Cheeseballs]

This makes uninitialized entities observable in content via the container events. Containers do a lot of things to entities as well so for example if you used these methods on a newly spawned wall, containers themselves would observe the uninitialized state by failing to unanchor it.

I'm not sure this approach is workable, deferring mapinit alone would need reviewing most mapinit implementations in content to make sure they're ready for the change.

It's been a while but I did test this on content and it worked fine, but yeah we shouldn't be inserting things into containers until the component has initialized. I can also adjust comments on the Init functions to clarify when they're called and what should and shouldn't be relied upon during them.

Content wise, I did testing to make sure nothing threw when I made this PR, that being said many of the errors this PR was intended to fix were silent so that's not exactly a saving grace.

[moonheart08]

This makes uninitialized entities observable in content via the container events. Containers do a lot of things to entities as well so for example if you used these methods on a newly spawned wall, containers themselves would observe the uninitialized state by failing to unanchor it.
I'm not sure this approach is workable, deferring mapinit alone would need reviewing most mapinit implementations in content to make sure they're ready for the change.

It's been a while but I did test this on content and it worked fine, but yeah we shouldn't be inserting things into containers until the component has initialized. I can also adjust comments on the Init functions to clarify when they're called and what should and shouldn't be relied upon during them.

Content wise, I did testing to make sure nothing threw when I made this PR, that being said many of the errors this PR was intended to fix were silent so that's not exactly a saving grace.

Yea the errornous behavior this casues would also be widely silent, with components made but not fully initialized.

[Princess-Cheeseballs]

@moonheart08 made it so it only delays MapInit now.

[moonheart08]

This is a breaking change, ensure it is documented as such.

[whatston3]

Looks alright. Found a few possible nitpicks, otherwise seems fine to me.

Depending on the appetite for the new API methods, #6784 is a minimal alternative.

Wish I'd have seen this before.