Proposal to move the responsibilities of the Box3DWorld over to an interface

[quattage]

This PR is contains an API addition that allows users to optionally provide their own Box3DWorld implementation and instance.
To do this, I've added two new constructs: the IBox3DWorld interface, and the WorldProvider delegate. API users are granted the freedom to implement their own IBox3DWorld while supplying an instance using WorldProvider. All internal references to Box3DWorld.Instance have been replaced with IBox3DWorld.Get, while Box3DWorld and Box3DEditorSimulation are now both implementing subclasses of IBox3DWorld

This allows worlds to be context-dependent while still easily maintaining the one-world-per-scene rule enforced by the singleton, but API users now have the option to break this rule should they so choose.

For integration's sake, the default implementation of WorldProvider defers to Box3DWorld.Instance, so this PR can act as a drop-in replacement with very few breaking changes to API users' code.

This change could cause some issues, since it allows API users the freedom to supply their own (potentially stale) worlds. To deal with problems caused by this, all implementing Box3D objects (primarily Box3DBody) no longer store a local reference to the Box3DWorld. They query for it using IBox3DWorld.Get() and immediately test for validity whenever the reference is needed. I think the flexibility of this system is worth the tiny bit of added overhead here, but I may have been a bit hasty with the implementation in some areas.

Let me know if this could use some improving or tweaking to better fit the API style you're going for. This PR does not include changes to the Samples, so I'd need to address those.

[Suvitruf]

Hello. Thanks for the PR! I like the idea of interface introducing. But I need find time and think about this changes in general 🙏