Don't use ScenePatchInstance for queued scenes

[cart]

Objective

Fix #24320

Solution

Don't use ScenePatchInstance for queued scenes. Instead, use QueuedScenes directly.

Testing

The example in #24320 now works.

[laundmo]

Simple fix. at the cost of a resource access, but i think thats inevitable here and probably costs less than the archetype move of the insert.

[laundmo]

Wait, is WaitingScenes the correct resource here? Theres also QueuedScenes which is what ScenePatchInstance was used for.

It seems like WaitingScenes will skip a lot of work which QueuedScenes does, and i'm not sure of the effects of skipping this work. Plus, the documentation of WaitingScenes is:

/// A [Resource] that tracks entities / scenes that are waiting for an asset to load which doesn't seem to fit.

[cart]

Wait, is WaitingScenes the correct resource here?

Yeah this is fine.

/// A [Resource] that tracks entities / scenes that are waiting for an asset to load which doesn't seem to fit.

Functionally, all "queued scenes" are "waiting for the scene to load". QueuedScenes largely just facilitates an initial check to see if the scene is loaded (and then it puts it in the "waiting queue" if it isn't). I'm thinking this initial check isn't actually necessary / theres probably some simplification potential here.

[cart]

@laundmo sadly WaitingScenes can't replace QueuedScenes (and can't be what we use for queue_X actions) because its used in a resource_scope, which prevents nested queues. Thats why the test is failing. QueuedScene has a double buffered mem-swap, which solves the problem. I'm going to switch to using that.

[cart]

I moved this loop until after the "asset load event" processing to ensure that we spawn queued scenes that are produced from the spawning of those scene asset loads now rather than waiting a frame.

I've also moved the mem::swap into the loop to ensure we check for newly queued spawns after spawning the current queue.