Fix problems caused by Ammo update

[MoritzBrueckner]

From #42:

To make strings work in JS, I had to update ammo.js to get access to the Ammo.UTF8ToString() function. This should not break anything hopefully.

...turns out, it did break something. Since we can't fix the first of the issues mentioned below (reported by @ QuantumCoderQC, thanks!) in haxebullet, I reverted the ammo update and instead implemented Ammo.UTF8ToString() via the Haxe standard lib, which luckily has this functionality as well.

---

The issues reported with the ammo update were as follows (this might become important again if we update ammo):

• Ammo._free() does no longer exist in the updated Ammo version although it's referenced by the JS code generated by emscripten, which caused an exception when deleting softbody objects. I assume it is optimized away during C/C++ --> wasm compilation (see this) because it probably isn't used by the C++ code, but only by the JS code generated from emscripten (which is probably generated after the wasm has been compiled).

  To completely fix this, one would probably need to apply something à la kripken/ammo.js@a4bec93 but for _free and then compile ammo again. The issue has already been reported at _free is not a function (ammo.wasm) kripken/ammo.js#404, depending on how much time I get I might try to build it myself and provide a proper fix.

• There was a small API change: in the previous ammo wasm, there were both GImpactCollisionAlgorithm (referenced in Bt.hx) and btGImpactCollisionAlgorithm, in the newer version only the latter exists. So to fix this we need to change @:native('Ammo.GImpactCollisionAlgorithm') here to @:native('Ammo.btGImpactCollisionAlgorithm').

  @luboslenco Do you remember whether bullet.cpp was generated automatically by webidl? The reason I'm asking is the following: I noticed that on the Haxe side in HL, we don't construct a GImpactCollisionAlgorithm instance to call registerAlgorithm() like in JS but instead use a btImpactMeshShape instance to then call the very same static registerAlgorithm() function (note the difference between the function name and the function body). btImpactMeshShape doesn't even have that function in Bullet, so I don't think that the linked code was generated automatically by webidl. This is perfectly fine, but I always thought that it was supposed to be automatically generated, so I'm a little confused about how to treat this file.

[luboslenco]

Do you remember whether bullet.cpp was generated automatically by webidl?

Hm really thought the file was autogenerated.. not sure why there would be a difference