Animate morph targets by name

[ellthompson]

Fixes #4314

Currently, all the morph targets that animate on a given node are included in a single AnimCurve, then referenced by their indices in the curves output data. This poses problems when morph targets are deleted from either a model asset or it's related animation asset, as the indices of each morph target in the curve will no longer match up with those found in the mesh's MorphInstance.

In this PR the glb parser instead creates a single curve for each morph target, which contains the morph target's name in the curve path. When the anim binder applies the value of each curve to their bound properties, it can then reference this morph target name to set the appropriate morph target on the MorphInstance. To support this, the MorphInstance class now contains a lookup table of morph names and allows the setting of morphTarget values using this lookup. Including individual curves for each morph target has the added benefit of making debugging much simpler as their keyframe output data is now stored in sequential order with a reference to the given morph targets name.

If morph target names are not present in the glb data, the index of each morph target is used as a fallback.

I have tested this on a set of model & animation assets which have had their morph target orders randomised.
Below you can see this animation playing on the current stable branch of the engine:

And here it is on this branch, making use of the morph target names to bind correctly:

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

[mvaligursky]

I'm not sure I understand what are you testing here? Existing weight? What if key which you use as index to an array is string .. what do you expect?

[ellthompson]

Sorry this was a bug from the refactor. Weights should be retrieved using the index instead of the key. Then if we cant retrieve a number from the weights array, we shouldn't be setting a new value or flagging the MorphInstance as dirty.

[mvaligursky]

Looks good to me, thanks.
@slimbuck - would you mind to give the binder / parser part a quick look as well, you understand that code more.