Improve no_std compatibility

[Jondolf]

Fixes #84.
Updated alternative to #170.

Parry technically supports no_std, but it is incredibly limited. SharedShape, partitioning, transformation, all of the polytopes, trimeshes, heightfields, and many more features are gated behind std. This makes it practically unusable for physics in no_std environments.

Additionally, the current no_std setup is quite confusing. as core is type aliased as std, and alloc is also only available if std is not. It would be much clearer to use core and alloc directly, and enforce this via the official Clippy lints.

This PR aims to improve Parry's no_std compatibility. This allows Avian to support no_std, and could be used for Rapier too. Prior to my changes here, I was getting numerous errors because SharedShape and Qbvh (among other types) required std.

Changes

This PR is large, but most changes are largely mechanical and fairly trivial, changing use of std to core or alloc.

Some notable changes:

• core is no longer type aliased as std in no_std environments. core and alloc are used directly wherever possible.
• Use of core over alloc and std, and use of alloc over std is enforced via Clippy lints.
• Most std feature gates have been changed to alloc instead.
• More dependencies have default features disabled.
• spade is now optional, and must be disabled for no_std.
  • Despite the crate itself having an optional std feature, I was getting errors about num-traits. It seems that this is because spade has default features enabled for most of their dependencies (link). robust has a no_std feature that we could manually enable, but num-traits just has std and libm, and spade unconditionally enables std. So this would most likely have to be fixed in spade.
• hashbrown is now used instead of rustc-hash for the HashMap and HashSet when enhanced-determinism is not enabled. This also changes the hashing algorithm from fxhash to foldhash. Aside from having no_std support, foldhash should also be faster for larger inputs, and has fewer hash collisions, see foldhash.

Things that still require std:

• mesh_intersections and split_trimesh (spade)
• Some debug things, like convex hull validation (there are some prints that we could probably replace with log)
• TriMesh::compute_connected_components (performs union-find using ena, which does not support no_std)

Usage without alloc is also still supported, though it is quite limited. It could be worth considering dropping no_alloc support, since practical uses seem very limited and having to feature gate it everywhere is annoying, but I will leave that for future consideration.

[bushrat011899]

Nice work! I know this looks like a large change, but it's almost entirely busywork with import names. This brings the project more Inline with how other no_std compatible libraries work, which should help with getting outside assistance.

[ThierryBerger]

That looks great! Thanks :)

That PR will need the changelog updated, but the PR description provides a good base for that 👍

[Jondolf]

I added a rough changelog entry, let me know if it's missing something or needs to be tweaked in some way

[sebcrozet]

Looking good, thanks!