Suggestion: Break CorePlugin apart into smaller, more modular plugins #7081
Description
What problem does this solve or what need does it fill?
CorePlugin currently has three disjoint responsibilities. It registers basic reflection types, it sets up the default task pools, and it sets up the frame counting system. For tiny bevy builds for things like game servers that run at fixed rates in single-threaded environments (see Valorant's 128-Tick Servers), it may be desirable to opt-in and opt-out of these things individually by using only a subset of MinimalPlugins (e.g. use the frame counter, but not the threaded task pools).
What solution would you like?
Split CorePlugin into three plugins with more focused responsibilities -- thread pooling, basic type reflection registration, and frame counter setup. Possibly grouped into a CorePlugins PluginGroup.
What alternative(s) have you considered?
A tiny bevy app could re-implement any of these things on its own, but that would likely be less future proof and more sensitive to API breaking changes.
Additional context
My personal use case is a game server that replaces the default schedule's core stages (First, PreUpdate, ..., Last) with fixed-update-tick equivalents (see gist for setup). It occurred to me while writing this that I would like to, for example, opt out of task pools on a single-threaded VPS that only runs the game's simulation.
I think there's also a potential issue here where CorePlugin, due to its name and nature, invites further growth into a multi-responsibility monolith as the engine expands. As a fringe benefit, splitting this up early into more domain-focused mini-plugins would be good, I think, for maintaining a culture of modularity at the core level.