Add doc-writing advice to Contributing guide

[alice-i-cecile]

Initial notes from Discord:

1. The first line of doc comments should be a minimal description.
2. Details of what the documented function / type do belong in their own paragraphs, separated by a line break.
3. If the usage is not immediately clear, or if there are subtle gotchas, add doc tests
4. If a method panics, mention that under a Warning header.
5. If a method or struct is unsafe, you must include a Safety header
6. Link to related types that are commonly used with or are alternatives to the documented type using [DocLinks].

These should be stored in a sibling to https://github.com/bevyengine/bevy/blob/main/.github/contributing/engine_style_guide.md, which should be linked in https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md

[Nilirad]

There are also some tips in the rustdoc book about writing good API documentation.

[Nilirad]

Some interesting tips from recent experience and discussion with @alice-i-cecile:

• Break lines at sencence-level. Eases versioning, forces to keep sentences short. For necessarily long sentences, break at clause-level. An exception to this rule is comments inside code blocks, because they are not wrapped. It's better to cut them at around the 100th column.
• Formatting guidelines. Formatting should be reasonably consistent among contributors. Make use of most Markdown features, but wisely (e.g. tables).

[alice-i-cecile]

More thoughts on stuff to add:

• advanced markdown tricks: tables, reference-style links
• standardized sections: Safety, Panics, Examples etc
• compile-fail doc tests
• assert_is_system
• ignore code blocks for error messages

[Nilirad]

Another useful pattern that I recently adopted: when documenting a data type, put under a “Usage” section:

• how an instance of that data type is produced or obtained,
• where it can be used.

[Nilirad]

In some cases I found useful to create should_panic doctests. A system can be made easily run to check if it panics with the following pattern:

/// # let mut my_system = bevy_ecs::system::IntoSystem::into_system(my_system_function);
/// # let mut world = World::new();
/// # my_system.initialize(&mut world);
/// # my_system.run((), &mut world);

[Nilirad]

If we end up using the advice of breaking lines at sentence/clause-level, we also should remove the wrap_comments option from rustfmt.toml. Otherwise, that would end up breaking comments where we don't want to.

The option is currently commented, however it is presented as being potentially uncommented on need (probably for some occasional workflows).