Update SpriteMesh in PostUpdate

[GiantBlargg]

Objective

Fixes #23590

Solution

Move SpriteMesh's add_mesh and add_material to PostUpdate
Sprites spawned during PostUpdate will still exhibit the problem, but this is an improvement.

Testing

Test with the reproduction from #23590 to see that it fixes the problem.

[PVDoriginal]

Wouldn't it be a better fix to turn those systems into observers instead? So they're ran immediately after a sprite mesh is spawned / changed no matter the schedule? Unless there's something blocking that?

[alice-i-cecile]

Observers are not well suited to processing bulk operations. It's also much harder to reason about and control the order that they run in. We should not ad-hoc change systems into observers without very careful analysis and profiling.

[PVDoriginal]

Observers are not well suited to processing bulk operations.

Fair enough. What about using the Last schedule instead of PostUpdate then? It's definitely less common for users to add their own systems in that schedule, so it seems like a better option altogether.

[PVDoriginal]

Also, it should be noted that these systems were an ad-hoc solution in the first place, meant to be reworked into something more long-term later down the line (possibly after the material unification).

But if this change makes them more pleasant in the short-term, I have no problems with it.

[GiantBlargg]

Fair enough. What about using the Last schedule instead of PostUpdate then? It's definitely less common for users to add their own systems in that schedule, so it seems like a better option altogether.

Running the systems in Last reintroduces the problem although I can't seem to figure out why.

I thought it might be check_entities_needing_specialization but running before or after made no difference in my test case. It's possible that running after would produce a delay that my case doesn't catch, so I'll add that ordering.