Arcify one-shot systems to enable SystemId templating

[ItsDoot]

Objective

I have a bunch of Bundle-style code that I want to replace with the new bsn! Scene-style macro:

pub fn rest_ui(/* system params */) {
    // my ui system...
}

// From
pub fn rest(mut commands: Commands) -> impl Bundle {
    (
        Rest,
        Name::new("Rest"),
        Activity {
            render: commands.register_system(rest_ui),
        },
    )
}

// To (ideally)
pub fn rest() -> impl Scene {
    bsn! {
        Rest
        Name("Rest")
        Activity {
            render: rest_ui
        }
    }
}

However, there is currently no simple way to implement a SystemIdTemplate because systems are not cloneable.

Solution

1. Introduced SystemArc<S: System + ?Sized>, a wrapper around an Arc<Mutex<S>>
2. Changed the one-shot system registry code to store SystemArcs instead of BoxedSystems
3. Added SystemIdTemplate that makes use of the new SystemArc type
4. Added a system_value function for wrapping system functions (see Future Work for potentially removing the need)

Note: Until #[derive(CoercePointee)] (or some other rust feature that gives user-land CoerceUnsized) is stabilized, one-shot systems cannot be used on no-std-portable-atomic because portable_atomic_util::Arc can not do Arc<T> to Arc<dyn Trait> conversions like std::sync::Arc can.

Testing

• Added a unit test for SystemIdTemplate.
• Added to the callbacks example demonstrating how to spawn SystemIds via BSN scenes.

Future work

• I believe we can remove the need for wrapping with system_value by introducing SuperFrom/SuperInto traits a la Dioxus and using it in the bsn! macros in-place of the implicit .into()s.
• SystemArc lays a bit of the foundation for Arcifying Schedules.

---

Showcase

You can now spawn components containing SystemIds via bsn! macros:

#[derive(Component, FromTemplate)]
struct Callback {
    system_id: SystemId<(), ()>,
}

fn my_scene() -> impl Scene {
    bsn! {
        Callback {
            system_id: system_value(|| {
                println!("This is a callback spawned via a scene.");
            })
        }
    }
}

[laundmo]

I'm pretty sure the fact all registered systems have changed over from BoxedSystem to SystemArc is gonna cause some performance regressions.

See the comments for an idea which would not require this, tho i'm not sure how doable it is.

[laundmo]

To me, this reads like each time clone_template and then build_template are called, a new SystemId would be registered. I don't know if this has any negative effects, as the Arc means it'll be the same underlying dyn System, but at least it produces more SystemIds than i think should be necessary.

Idea: Would it be possible to store something like a Either<BoxedSystem, SystemId> in SystemIdTemplate::System (behind a mutex or similar), such that the SystemId from the first time this system is registered can be re-used for subsequent times this system gets registered?

If that works, it would, i think, remove the necessity for SystemArc by moving the Arc<Mutex> needed to make a system clone-able for clone_template into the SystemIdTemplate scope.

Another idea i had was only allowing a set kind of system in Self::System, or having 2-3 variants for different kinds of systems, as some like FunctionSystem implement Clone

[laundmo]

This is one of the places i fear a performance regression especially for heavy users of one-shot systems might happen

[laundmo]

I'm concerned that completely switching over every RegisteredSystem to SystemArc will have performance implications even during on-shot system calls.

[ItsDoot]

Closed in favor of #24087