bevy_remote pulls in Bevy's rendering

[SpecificProtagonist]

bevy_remote does not need to do any rendering and should work on apps that don't use Bevy's rendering stack.

Currently bevy_remote depends on bevy_dev_tools for schedule configuration data, but bevy_dev_tools unconditionally pulls in Bevy's renderer (as its main purpose is to display useful information).

[alice-i-cecile]

The schedule configuration data should probably be in bevy_ecs, possibly feature-flagged.

[marcotoniut]

Concrete cost from a 2D project on 0.19, in case quantified impact helps the design discussion.

This project uses BRP heavily for agent and MCP-driven inspection, so bevy_remote is on in dev builds. It keeps bevy_pbr and bevy_light in the graph, 69.0s and 38.8s of codegen respectively, roughly 4.5% of a clean debug build's CPU, for a game with zero references to StandardMaterial, Mesh3d, lights, Camera3d or bevy::pbr.

It also caps feature trimming. Switching to default-features = false, features = ["2d", "ui", "audio"] cut the clean build by about 19%, but bevy_pbr and bevy_light survive it entirely, because bevy_remote to bevy_dev_tools requires them independently of the 3d umbrella. A 2D project cannot drop the PBR stack at all while BRP is enabled.

Worth noting that schedule_data needs nothing render-related: serde, ron, bevy_utils and thiserror, plus bevy_platform on 0.19. bevy_pbr is reached only by dev_tools/diagnostics_overlay.rs (StandardMaterial, MaterialAllocatorDiagnosticPlugin, plus the deferred and prepass imports in debug_overlay.wgsl.) If moving schedule data into bevy_ecs is the longer path, making bevy_pbr optional in bevy_dev_tools behind an overlay feature would unblock consumers meanwhile, the same shape as #18343 for bevy_gizmos.

I'm trying to trim compile times, that's why I'm looking at this right now.