Reconsider negative skinning weights

Thank you for the clear tutorials, specs and welcoming forum. I'd like to understand better _why_ does the spec restrict skinning weights to be non-negative?

> The joint weights for each vertex MUST NOT be negative.

Specifically, when specified with Component Type `float`?

I agree with this [previous thread](https://github.com/KhronosGroup/glTF/issues/1213) that most tools for manually authoring weights focus on non-negative weights. However, negative weights have been explored in more procedural contexts, e.g.:

1. compressing and baking mesh animations, see e.g., "[Skinning Mesh Animations](http://graphics.cs.cmu.edu/projects/sma/)" and the long list of its descendants
2. procedural add-on skinning effects, see e.g., "[Velocity Skinning for Real-time Stylized Skeletal Animation](https://velocityskinning.com/)"
3. automatic skinning weight creation techniques, e.g., "[Mean Value Coordinates](https://www.cse.wustl.edu/~taoju/research/meanvalue.pdf)", "[Linear Subspace Design…](https://www.cs.utah.edu/~ladislav/wang15linear/wang15linear.html)"

It seems worthwhile for gltf to embrace these, other and any future exploitation of linear blend skinning in real-time animation.

Meanwhile, it appears that [morph target weights are correspondingly unrestricted](https://github.com/KhronosGroup/glTF/issues/931).

_FWIW, Negative weights can be _emulated_ by adding more bones (+1 for any bone with a negative weight) and negating their transforms. Obviously, this potentially doubles the number of bones per mesh, and increases storage rather redundantly._

Start by reviewing the quoted skinning-weight requirement, the linked previous thread, and the cited research on negative weights. Determine whether the specification should change for float weights, then document the compatibility and implementation implications and the resulting specification decision.

Written by the indexing model from the issue text.