Add the ability for SubApps to have a custom update function

[moonheart08]

Objective

Implement the solution proposed for #18185

Solution

Added a new field to SubApps, update_fn, which contains the function to invoke for running SubApps::update(). SubApps::update() was preserved to allow invariant update behavior to be introduced in the future if necessary, and for ease of use. Broke out the Default implementation for SubApps so that the update function is set by default.

  let app = ...;
  // App update is unsuitable, let's do something else.
  app.set_update_fn(|sub_apps| {
    println!("Hello! I did a thing! Probably!");
    ...
  });
  
  // Now invokes our update function internally, so custom runners like the Winit runner will now run our update code!
  app.update();

Testing

PR opened to run bevy test suite (my poor laptop would get mad), API fits the constraints I described in https://canary.discord.com/channels/691052431525675048/742569353878437978/1347321570603044999, full convo transcribed:

[15:34]moony (Kaylie!): Is there some recommended way to customize the subapp update order? I'm doing my own shenanigans with extract and runtime addition of subapps and would rather not have the defaults.
[15:35]moony (Kaylie!): atm the blocker seems to be making whatever i do work with the existing winit code
[15:37]moony (Kaylie!): (I'm already targetting latest instead of stable due to needing .sub_apps() so if it's specific to latest that's still good to know)
[16:26]moony (Kaylie!): i have worked out a scrungly solution for the meantime: App in my App.
[16:43]Alice 🌹: Not really, this is kinda half-baked still
[16:43]moony (Kaylie!): just being able to replace update() with my own func would be sufficient tbh and likely covers most uses
[16:44]moony (Kaylie!): filing an issue about that approach atm
[16:45]Alice 🌹: Okay sweet; that's appreciated. We haven't done a ton of digging into the exact ways that users might want to extend / modify this design, so experienced-based opinions are really useful
[16:45]Alice 🌹: Mostly my reaction to subapps and windowing is :pain2: due to the difficulty testing and all of the platforms, so changes there are really slow currently
[16:46]moony (Kaylie!): my exact constraint is I'm adding some arbitrary N set of scene subapps for worlds the player could be in, and allowing the user to swap between them
this is very easy to do if i can just control which subapp render is running extract on (and otherwise control the extract flow myself)
[16:46]moony (Kaylie!): in other words a single "main" subapp isn't the right approach for my experiment
[16:47]Alice 🌹: Interesting. What's the ultimate motivation for that? For the most part my opinion is "don't use subapps if at all possible", and I'd generally use something like states and scenes or something for that design
[16:47]moony (Kaylie!): isolating those scenes, because UGC
[16:48]moony (Kaylie!): if one scene gets completely mucked up for whatever reason the user should be able to just close or leave it and be fine
[16:48]Alice 🌹: Aha, interesting! Okay, that makes more sense to me

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨