Animator construction should use builders, too

[DarthSharkie]

While animators aren't as parameter-heavy as particle objects, they can take several parameters when constructing. Therefore, like objects, they should adopt the Builder Pattern and deprecate their public constructors.

One reason for this is to allow defining rotation, offset, or both when building an animator. Right now, the telescoping constructor pattern makes this difficult because both rotation and offset are modeled as Vector3f objects, so they're indistinguishable in constructor function signatures. A builder pattern will fix this by naming each parameter as its provided, such as .rotation(rValue).offset(oValue).build(). This should also help with animators that take lists or vararg arrays of parameters, since builders can accumulate multiple values for the same field.

Animators also have several properties, which makes constructor methods difficult to read. IDEs can help by choosing to show parameter names inline, but that doesn't help on GitHub or in a command line environment.

Builders that use super classes can be difficult to get right, since builder methods often declare a return type based on the class in which they reside. This may complicate the approach a little, but should be manageable.

[DarthSharkie]

This is ready, but pending #49.

[DarthSharkie]

Fixed in #49