Support for user allocator

[Pierre-Terdiman]

We already discussed it so I know it's on your list, but I'd like to officially ask for adding a "user allocator". The goal would be to allocate all objects (not just the temporary ones) thought this allocator, so that we can accurately track memory usage.

Thanks!

[jankrassnigg]

Would like to see this as well. Might mean that you'd need to get rid of using std::vector and use a custom array class.

[jrouwe]

I was planning on using the allocator class that you can provide to std::vector, maybe I'll create my own container classes at some point in the future (for now it is not really in the way as it is mostly used for long term storage).

[urosidoki]

I have a problem that might be related to this (not sure). I have my own custom allocator where I keep track of memory, but when I am shutting down the app, I got tons of memory leaks from the memory allocated during the call to JPH::RegisterTypes();
Would be nice to be able to have a certain level of control over when I do want to deallocate that memory.

[jrouwe]

Can you try #146 and call JPH::Factory::sInstance.Clear()? My guess is that your leak detection code runs before the static destructors are called. I'm not 100% sure that this will fix it as some STL implementations seem to allocate memory even if the map is empty.

[jrouwe]

I did some more work on #146 and removed most of the memory allocated by global constructors and made the application responsible for newing/destroying the factory. There are a couple of allocations left by the global constructors, most notably the SphereShape used by Body::sFixedToWorld, but I believe that that should not be an issue for your particular case.

[jrouwe]

Merged #183.

[sherief]

YAY!