Improve performance of the contact algorithm and/or make contact handling optional

[stfnp]

The current way contact handling is done might be a performance bottleneck. Mainly the broadphase algorithm and its implementation. Possible actions:

• Look at the implementation and try to optimize it. Does it allocate memory somewhere?
• Find a 3rd party library that is faster and more polished
• The algorithm (sweep and prune) is fairly generic. Make some more assumptions and come up with something more specialized.
• Make it possible to turn off contact handling in the simulation options for bows that don't need it

[stfnp]

Idea: Fixed mapping of string nodes to limb segments, with some tolerance

• Every string node is assigned a position on the limb by arc length. An adjustable tolerance (e.g. 10%) is applied to that position, this is the interval in which we assume the string node can contact the limb. Create contact elements for every combination of string node and limb segments inside that interval.

• Another adjustable setting determines how much of the limbs length, starting from the tip, is covered by contact handling. Default is 100%, which can be reduced for better performance down to 0% (no contact handling at all).

Advantages:

• Much simpler, no broadphase algorithm needed
• Makes use of the known topology of the bow, might be faster
• Fixed-Size elements

Questions

• General: Can we get some indication of failed contact handling, to provide better error messages when a simulation fails?

[stfnp]

The new solver uses a different string model with much simpler contact handling. Turning contact handling off might still be an interesting option though, so I'm keeping this open.