Added a more performant normalizeAngle()

This is a more performant version of normalizeAngle(). It correctly clamps the value of the angle to be in the -PI..PI range, applying a proper modulo-like conversion. The big deal is that it uses no while() loops, so it will have consistent performance, regardless of the angle.

---

I'm working on some code that is supposed to be running for days without stop or intervention. I noticed that after a few hundred hours, certain functions started taking more and more time to execute, and that Starling's `normalizeAngle()` was by far the biggest culprit in increasing execution time.

There were no memory leaks in my code. However, I have several particles (sometimes hundreds of them) and sprites that rotate endlessly. I do so by taking the current timer value and applying it as the rotation angle of the image. This means that the rotation property of the image would, at times, contain huge numbers (think of the typical `rotation = getTimer() / speed`).

Looking at the code of `normalizeAngle()` quickly made me realize what the problem was. After a few thousand rotations of my particles, updating the rotation would trigger long loops because of the while() blocks used in the function.

I fixed my code with my own range-modulo code, but it would make sense to have this on the public version of Starling since more people may run into this problem. The suggested code does that.

The solution contains no loops so it will always perform the same. It *does* have a difference of resulting values compared to the old version when the rotation value contains a few million rotations, probably because of loss of floating point precision. That said, I believe the new equation is more precise since it's not trying to add or subtract PI from a value many many times.

Here's some quick benchmarks of the function itself, for 1000000 conversions:

Rotation of "-1":
Old: 294ms, new: 335ms

Rotation of "1": 
Old: 302ms, new: 333ms

Rotation of "4":
Old: 299ms, new: 327ms

Rotation of "20":
Old: 315ms, new: 329ms

Rotation of "200":
Old: 673ms, new: 320ms

Rotation of "2000":
Old: 4111ms, new: 336ms

As you can see, the new method has a ~10% impact in performance when converting most valid ranges. But the impact on ranges that are far out of the range is brutal.

(This ~10% impact is mostly solved by using a TWO_PI constant, by the way, but I just didn't want to alter the class too much)