QueryOptions parameters (GjkOptions)

[ThierryBerger]

Following discussion on discord, a shape cast of a ball sometimes fails when it should not.

• Related to https://github.com/dimforge/parry/issues/180
• Would fix:
  • https://github.com/dimforge/parry/issues/70
  • https://github.com/dimforge/parry/issues/317
  • https://github.com/dimforge/parry/issues/193

Current status

• [x] Exposes gjk parameters through GjkOptions, this is very breaking as it impacts PointQuery trait.
  • [x] DefaultQueryDispatcher stores relevant options to pass to their algorithms.
    • [ ] store an option dispatcher inside the DefaultQueryDispatcher to handle user-defined algorithms (and more elegantly our convex polygons).
      • [ ] Fix intersection_test_point_query_ball (https://github.com/dimforge/parry/pull/298/files#r2230938921)
• [x] Use a QueryOoptionsNotUsed in algorithms to make it easier to understand which paths need an option and which don´t. Ideally an associated trait would be used but it makes it difficult to mix different shapes...
• :thinking: Maybe we should consider making new methods to pass parameters, like contains_local_point_with_option ? to make the API more straightforward by default, but I'm not a huge fan of duplicated entries
• :thinking: Can we improve the type safety ? Currently an incorrect parameter leads to using default and logging a warning, I think it's good enough :tm: but not amazing

Before this PR:

After this PR, with customizable Gjk epsilon changing each frame:

Screencast from 07-24-2025 04:49:01 PM.webm

I added an example for compound shape point query (using convex polygon, to test dispatching gjk options), and the result was showing false negatives (without custom gjk options ; multiplying the epsilon by 100 fixes it.):

Screencast from 07-16-2025 04:09:26 PM.webm

[ThierryBerger]

• Current CI failing due to https://github.com/dimforge/parry/pull/364