Add bevy_rapier3d-based backend

[barsoosayque]

Since avian3d and bevy_rapier are pretty similar, rapier_rerecast turned out to be a pretty much a copy past of avian_rerecast with minor differences:

1. Rapier doesn't have ColliderOf, so I have to find the body manually in collider_backend.
2. In impl ColliderToTriMesh for Collider, I have to scale the collider by 0.5, otherwise it is too big.

I also took the liberty of adding the new backend to readme.

There is also a copy-past example for rapier_rerecast based on the avian example, and here is side-by-side comparison:

[barsoosayque]

I've been testing this more, and it seems that the actual trimesh colliders shouldn't be scaled by 0.5. I'm not sure what's going on, but this PR shouldn't be merged until I figure out what's up with scaling

[SFilinsky]

I had similar issue with custom implementation of Rapier backend, but I only support Cuboids yet.

The problem was that cuboid.half_extents() in Rapier already considers object scale and I applied scaling twice.

Maybe it's similar API quirk

[SFilinsky]

Also, please make sure to include non-axis aligned objects in tests to cover rotations, and same for scale. All current tests have objects with defauit rotation and scale 😄

[barsoosayque]

Okay, so basically the rapier implementation was alright, nothing should be scaled. It was a copy-paste error from avian's example: rapier uses half sizes for cuboid colliders, while avian uses bevy's full sizes. I wrote tests for rapier backend to check sizes of converted trimeshes, everything seems to be just fine.

I have also rewrote avian/rapier examples to use more shapes in a fun way:

[barsoosayque]

Oh, one more thing. Avian backend uses subdivisions = 10 for trimeshes, and my initial rapier backend implementation did so too, but I have found in my tests that it's too low, at least for ball/sphere colliders. 16 seems to be optimal number of subdivisions