Initial draft of roadmap page

[Freyja-moth]

Added a new roadmap page to the website.

Project list subject to change

Each project should include

• Image showing it off (if possible)
• Small description on what it is
• Section on how users will benefit from it
• Section detailing the steps to get there + rough timespan
• Section explaining how new users can contribute

[Freyja-moth]

From @alice-i-cecile for what is going to be included

Tooling

• basic scene editor
• entity inspector
• project templates

Critical improvements

• better scenes (composition, inheritance)
• improved asset processing
• full suite of UI widgets
• production-grade audio solution
• input/action mapping

Docs and marketing

• deny(missing_docs) on every crate
• basic book
• project showcase on the site
• better sorting of Bevy Assets

Vital but post-1.0

• particles
• animation editor
• physics
• schedule visualization
• interactive dev console

I will get around to doing them but that will take time.

In the meantime feel free to write these and make a pull request on my fork, it'd be very much appreciated.

[alice-i-cecile]

Preamble

As a bit of background, I've been talking about this work with Freyja in DMs. The rationale here is: "people want to understand what Bevy needs to do to be Production Ready".

Goals are great for relatively short-term, operational planning, but at least so far, have been fairly driven by the needs and desires of user-contributors. To a new user, things like "relational queries" or "archetype invariants" (features I badly want) both make no sense, and seem like a chaotic distraction from the Important Stuff needed to make games.

In some sense, that's true! Bevy's existing user base is not representative of the set of people who want to use Bevy, because they're not bothered by the critical missing features (like a scene editor).

But for better or worse, Bevy, as an open source organization, cannot simply say "thou must only work on things which get us to MVP / The Editor". Contributors have their own goals (which may or may not align!), and we cannot dictate what folks work on.

As maintainers, we could simply refuse to merge / review / "waste time on" work that does not push us towards the MVP vision. But we shouldn't: keeping the Bevy community (as both users and contributors) healthy and happy is really valuable, and reviewing and merging stuff that's been contributed for free is extremely efficient!

However, there are a subset of current/potential community members who want to understand a) what do we need to do to get to MVP.

Structural feedback

1. I really like having this as a top-level heading. Not convinced on "Roadmap" specifically since this doesn't follow the classic format, but it does basically communicate the right thing to the target audience.
2. We should be sure to avoid jargon (e.g. "Bevy scene notation"). The target audience is "experienced game devs who have never used Bevy".
3. I like the general Motivation/Description/Next Steps/Contributing format for each work item.
4. The tooling / engine improvements split is nice (I'm glad to see how that worked out). We should think to see if there's clearer names.
5. I think that this would be much clearer / easier to read as a blog post-styled page, possibly with folding sections.

That last point is complex, and worth breaking down:

• This "Roadmap" would benefit from a fair bit of contextualization (like what I gave above) on project management in open source.
• In that preamble, we should have a clear elevator pitch on what our current goal is. Think "For Bevy 1.0, we want to let small mixed teams create games", but you know, worded well.
• Not all items will have compelling screenshots, and we should not try and shoehorn this to do so. However, the current design looks bad when they're missing.
• I think readers will quickly give up if you force them to navigate between multiple pages