Add guidance for upstreaming crates

[alice-i-cecile]

I'd like to see us upstream more stuff. It's a challenge, but a different kind of challenge than greenfield work, which mostly comes from solving problems in the ecosystem crate by modifying the ecs or the other core crates (the for bevy_picking this was adding bubbling to observers). IMO it's something you're usually going to need engine-devs for (which was the issue with the student group, not their fault).

For future up streams, this is probably how I'd work it:

1. Design and implement necessary engine features, and in parallel add polish to the ecosystem crate.
2. Copy all the important files from ecosystem crate verbatim into the engine repo (leave stuff out of the workspace/example tree).
3. Mock the up-streamed crate to get it compiling (even if it's broken) and write specs/tests.
4. Integrate new ecs features and fix broken stuff until it meets the specs/tests.
5. Iterate on the up-streamed api with feedback from early adopters (this was crucial for getting bevy_picking ready for release).

I probably wouldn't try to plan more than one of these stages at a time. It's better to bite off manageable chunks.

Originally posted by @NthTensor in bevyengine/bevy#16431 (reply in thread)

[alice-i-cecile]

This advice / structure is great, and can be taken as the building block for a new section of the Contributing Guide.