Enable specifying extra margins for objects in DynamicAABBTreeArray broadphase manager.

[torresl-google]

Before this change, if a user wanted to do collision checking with a security margin, they couldn't use a broadphase manager because the broadphase may discard pairs of objects whose AABB's do not overlap.

This change allows users to specify margins on CollisionObjects that they add to DynamicAABBTreeArrayCollisionManager. The broadphase will operate on these objects as if they had larger AABBs, but the objects themselves are unchanged.

This change enables the following useful patterns:

• Add objects with a margin m to the broadphase, then use a CollisionCallback that checks for narrow phase collisions with a security margin equal to m. Now we can do collide() queries and catch all collisions within the security margin.
• Create two separate broadphase managers, where both have objects with margin m. When checking for collisions between the two managers, you can set the narrow phase security margin as high as 2*m and detect all collisions.

I don't consider this PR complete at all! I wanted to use it to start a conversation:

• Is this feature useful to other people?
• Does my implementation actually work as expected?
• Should it be generalized to other broadphase managers?

[lmontaut]

Hi @torresl-google ! You're right that the broadphase managers in coal don't deal with the security margin of the various narrowphases by default.

For reference, here is how we deal with it in pinocchio: see here, inside the update method of pinocchio's broadphase manager (which inherits from coal).
What update does: for a given object in the scene, it looks at all the collision pairs it is involved in and retrieves the maximum security margin of all these pairs. It then inflates the AABB of the object by this maximum security margin.

You could do something similar in your application:

1. update the objects' AABBs so that they take into account the security margins as you would like (e.g. what is done in pinocchio's broadphase manager update).
2. run the broadphase using coal's default CollisionCallBackCollect (this simply stores the pairs of objects that the broadphase has considered as overlapping) or using something more tailored to your application (see the example of pinocchio's CollisionCallBackCollect).
3. run the narrowphase with the "right" security margin for each pair stored in CollisionCallBackCollect.

Getting back to Coal: I think the value of the broadphase managers in Coal is the implementation of various methods that construct the different data structures and run the broadphase, given a set of objects and their AABBs. Coal proposes default callbacks, but it is quite flexible to suit various specific needs (again, cf pinocchio).

TLDR: I would suggest users to inherit from coal's broadphase manager (to benefit from the core algorithms) and implement their own callback in their application. I am not convinced it's the job of coal to handle specific use cases.

@torresl-google what do you think? Am I missing something?