Case for better animation control when using nodes

Following [this forum topic](http://forums.armory3d.org/t/a-case-for-improved-animation-control-when-using-logic-nodes/) (and @zicklag's suggestion), I am making a case for better animation control when using nodes.

For large node networks, having to use 2 or 3 nodes to control an animation causes significant network blow-up and node-spagetti. To counter this, animation control nodes should incorporate loop/speed as per [issue #979](https://github.com/armory3d/armory/issues/979).

@luboslenco suggests in #979 (somewhat implictly) that nodes with more sockets hamper the learning curve and that smaller modular nodes and node groups are a better approach. I do not agree: please see the node network in the forum link, where I did just that.

While I do agree somewhat with @luboslenco on adding many sockets/functions to a node, having a concise approach to playing an animation with a single node makes for smaller node networks which are easier to maintain and have much less chance of introducing errors (debugging them is a pain). It will actually shorten the learning curve, even if that node takes more time to learn/understand. @luboslenco: please reconsider.

Possibly related: [issue #1018](https://github.com/armory3d/armory/issues/979) shows a behavior discrepancy between different node setups. I would expect any approach to have the same behavior.

*(drag & drop zipped .blend file here)*

Start with the linked forum topic and review related issues #979 and #1018 to understand the proposed animation-node behavior and the reported discrepancy. The issue does not identify implementation files or tests; completion would require an agreed approach and consistent behavior across the referenced node setups.

Written by the indexing model from the issue text.