Removed Box2D 2.2.1, and replaced it with Box2D 2.3.0. Changes to b2World and MOAIBox2DBody to support Box2D 2.3.0.
Merge pull request #875 from fivevolthigh/fvh-box2d-contrib

Removed Box2D 2.2.1, and replaced it with Box2D 2.3.0. Changes to b2Worl...
The switch to the Box2D 2.3.0
Add MOAI_HTTP_CLIENT.
Added accessor.
Add propList function to MOAIPartition.
Merge pull request #876 from moai/feature-getters

Feature getters
Added additional 'wake' parameters from Box 2.3.0 to various force applying functions.
Expose Box2D 2.3.0 'motor joint' to MOAI. See Box2D 2.3.0 Testbed 'motorJoint.h' for details.
For Box2D 2.3.0, added 'wake' parameters to various MOAIBox2DBody force applying functions.
Merge pull request #878 from fivevolthigh/fvh-box2d-add

Fivevolthigh Box2D 2.3.0 Additions
Update ReadMe.
Merge branch '1.5-development' of https://github.com/moai/moai-dev into 1.5-development
An example that shows the Box2D 2.3.0 MotorJoint at work. Click the mouse to move the prop. The Box2D MotorJoint will return the prop to the starting position over time.
Removed irrelevant constant.
Merge pull request #880 from fivevolthigh/fvh-box2d-motorJoint-sample

Box2D 2.3.0 MOAIBox2DMotorJoint example
Remove call to getcwd for Android

In some cases, getcwd returns null which leads to a segmentation fault.
Moreover, the call isn't even needed because the Android host sets the working directory with a JNI call afterwards.
Merge pull request #909 from DanielSWolf/fix_build

Fixed build on Windows. Force link to msvcrt dll instead of static
MOAIParticleSystem.cpp: Even when wrapping, respect size of sprite array.

When using wrapping with the particle system, GetTopSprite() could return
a pointer to a sprite outside the actual reserved array, because it
always returned the address of the Nth item in the array, even if the
array didn't have that many items. Add a % operator to parallel the
usage for computing the index in PushSprite().

PushParticle() doesn't have a corresponding problem, because it doesn't
use the array as an array, but rather maintains a free list of available
particles.
Add user-settable registers for particle scripts

The idea here is to provide a way for live parameter updates for
a particle script. So, we introduce a new kind of register, a
"live" register. Live registers are associated with the particle
script, not with a specific particle. The intended use is that
these allow you to prepare arbitrary values, stored in a
particle script, then have the script use those values.

If you use these values in the initialization script, they're
fixed once a particle is created. If you use them in the render
script, they continue to update live throughout the life of the
particle.

Added a new example (particles-registers) to illustrate how to
use this.