Speeling
Comment out an Flump Library Asserts call which is taking a measurable amount of time.

Since PlayN Asserts are not actually in any way removed for production (despite what the documentation would have you believe), having this assert here does noticably ungood things to performance while loading a flump library.
Fix bug where quickly toggling mute on a sound board could NPE.

In particular, if the board has a looping sound (music), the timing of faders could get interleaved such that things were inconsistent.
Use assert in lieu of Asserts.
Guava 13 was quite a while back. It's up to 16 these days.
When a TextWidget autoshrinks the text to fit, correct the height for vertical alignment.
Added ability to complete Animation chains instantly

-Completed animations will instantly apply the final result of the
animation, and propagate the completion call to the rest of the
animations in the chain.  Animations which have already been completed
manually or automatically by the animator will have no effect.
-Abstract method for complete() added to Animation (can be called
through the Animation.Handle), and implementations for existing
TriplePlay Animation subclasses
Oh god, the trailing whitespace
For loop that business up
Cancelled -> canceled

I really can't decide which spelling I hate less, but I definitely
hate a comment saying one the line above using a variable saying
the other.
No recursion needed.
Vastly simplified animation completion.

Firstly, the logic was scattered all over the damned place and the copies
weren't consistent. AnimGroup was checking canceled, but Animation wasn't. The
duplication is now gone and the logic is necessarily consistent because it only
exists once.

I changed the canceled check to cause things to blow up. Either you cancel()
your animations or you complete() them. You don't mix and match. There's no way
we can do anything reasonable in such circumstances, so we disallow it.

The makeComplete() (nee complete()) method is now documented as being
idempotent so that we can now simply go through the whole animation chain and
mark every animation is complete whether or not it has been previously
processed.

If a layer is in an animation chain multiple times, like:

  moveTo(layerA, pointA).then.moveTo(layerA, pointB)

and the first animation has already completed before complete() is called, then
the first animation will move layerA to pointA during the completion process,
but the second animation will move layerA to pointB immediately afterwards, so
aside from a miniscule amount of extra effort (possibly offset by vastly
simpler completion logic) there will be no visible funny business. Everything
will end up where it should be were the animation chain allowed to complete
normally.

It is possible that a totally separate animation chain was queued up to
manipulate a layer after the first one completed, but then that first one went
on to do other things and was complete()d later, thereby stepping on the toes
of the second spawned animation chain. But arguably you should be completing
all animation chains in that case and completing them in the order that they
were spawned, so you should still be OK. Though you really shouldn't be doing
such crazy shit in the first place.

I also removed Repeat _isCompleted tracking because it didn't make any sense.
At first I thought animation chains were intended to be reused, but that's not
possible. complete() also cancel()s the animations, and once an animation is
cancel()ed, it can never be reused. Moreover, once an animation is cancel()ed,
next() will never be called on it. So there are no circumstances in which
Repeat would need to return something special from next() after it had been
complete()d.
Missed a spot.
Simpler. Courtesy of Ray.
Let's just do this right now so that there are no gotchas later.

Why do I have to argue for this?
HashSet is already a wrapped Map. This is more performant.
This looks a bit uglier but this is exactly the kind of thing that
an identity map is used for.