Add bevy-components feature

[deontologician]

After bevyengine/bevy#2254 there is a requirement that anything used as a component must derive Component explicitly.

From what I can tell, most of the data structures that are used as components in bevy_rapier are defined in rapier, but SharedShape is re-exported from parry, so the annotation has to go here.

I attempted to minimize the effect on parry by:

• putting it behind a feature flag
• minimizing the number of lines of code referring to bevy in parry
• turning off default features in bevy to reduce the effect on compile time

One thing I'm unsure of is specifying the version of bevy. I've included it as 0.5 here, because that's what's on crates.io right now, but this code won't actually work with that version, only with a particular branch of bevy in this PR (which will hopefully land soon):

bevyengine/bevy#2305

[MiniaczQ]

I don't think a feature like this should belong in the main branch. It's only a temporary fix until we get better syntax to do it properly from only the interop crate.

[Aceeri]

@MiniaczQ I'm not sure there is much of an alternative to this currently (maybe doing just wrapper types in the interop crate?). I don't think we are getting better syntax for doing this anytime soon based on looking at rust-lang/rfcs#2393.

[deontologician]

@MiniaczQ I'm not sure there is much of an alternative to this currently (maybe doing just wrapper types in the interop crate?). I don't think we are getting better syntax for doing this anytime soon based on looking at rust-lang/rfcs#2393.

It sounds like wrappers in the interop crate is the way to go, but that requires the most knowledge of the innards. This change was relatively easy to make as an outsider without changing how bevy_rapier works internally.

[sebcrozet]

Thank you for this PR @deontologician! I’m closing it since I ended up using wrapper types instead: dimforge/bevy_rapier#102.