Store animation keyframes in binary format

This relates to QtQuickTimeline component as well, but that doesn't seem to be an available component type in Jira.

The issue is that when importing animations from 3D editors, each property animation of each item will have a keyframe for each frame of the animation.  For example:
The VC example from the glTF2 samples generates a QML file that is 206000 lines long and is about 6MBs.  I investigated why, and it makes sense.  each animated object has about ~900 keyframes, and is animating 3 properties each.  So just one object would generate around 900 * 3 * 4 = 10,800 Lines of code which means it only takes 20 animated objects to hit that 200,000 Lines of code (which is exactly what it is doing).  
The glTF JSON file is still large at 20,000 lines of code, but much of that is just defining where to "sample" the property when doing the animation, and the actual data is stored in the binary buffer.
I was thinking about how we could reduce this, but there is no way to accurately represent some animations.
In the case of the VC test, there is a 720 Frame animation which is presumably assuming 30 seconds at 24FPS (what 3d editors typicaly default to).  I also think it is 30 seconds because assimp things it is 30,000 frames in QML.  So it's not going to be so unusual to script 30 second animations.  The second issue is that when you export a 3D scene you typically bake the keyframe values by sampling the values along the curve, which is exactly what was done in the VC test.
 
So knowing that, we need to be able to represent that use case, but specifying each keyframe as 4 lines of QML code isn't scalable.  So it should be possible to specify these keyframes as a binary buffer of data.  I created a proof of concept that stores the keyframes as binary files which can been seen here:
https://codereview.qt-project.org/c/qt/qtquick3d/+/304671
https://codereview.qt-project.org/c/qt/qtquicktimeline/+/304670
And this resolves the issue (though it should be cleaned up).
 
This change in the case of the VC example brings the QML file size back down to about 5000 lines of code instead of 200,000+ and the binary data is also quite small.
 
Extending the QtQuickTimeline module to support binary keyframe data also has implications in Design Studio because the timeline editor needs to be able to consume and write these binary keyframe files as well.  We also need to establish a file format for this keyframe data (I just used QDataStream in the proof of concept).