Animation Tracks: Convert to es6 classes

[ianpurvis]

Supports #19986

[ianpurvis]

I noticed this pattern where prototype methods are undefined to drive fallback logic in base KeyframeTrack. It feels kind of wrong to mutate the KeyframeTrack interface, although I guess if these can be considered internal it doesn't matter. No need to change now, just pointing it out as another candidate for some cleanup down the road.

[ianpurvis]

I debated whether or not to preserve these prototype properties. They should reduce memory footprint with a large number of animation tracks, though I don't know if that matters in real world usage. They seem better suited as static props than instance props? Anyways, let me know what direction is good and I can tweak this PR as needed.

Honestly, all of the inheritance doesn't seem that useful. In the long run maybe the track system could just be refactored with a more data-driven approach.

[mrdoob]

Thanks!

[mrdoob]

Btw, seems like Object.assign() breaks tree-shaking in Rollup. I'll change them to individual *.prototype.* =.

[mrdoob]

6100437

[Mugen87]

It seems this PR has broken KeyframeTrack serialization. This can easily be tested by drag'n'drop an animated asset into the editor and wait for the save.

https://raw.githack.com/mrdoob/three.js/dev/editor/index.html
https://github.com/mrdoob/three.js/blob/dev/examples/models/gltf/Flamingo.glb

The following runtime error occurs:

three.module.js:32997 Uncaught RangeError: Maximum call stack size exceeded

At this place:

three.js/src/animation/KeyframeTrack.js

Line 32 in 4d90e23

const trackType = track.constructor;

[Mugen87]

Fiddle demonstrating the bug:

https://jsfiddle.net/th1m48a9/

@mrdoob Since the release is tomorrow, this is in some sense a blocker. If not fixed in time, it's better to revert this PR.

[ianpurvis]

@Mugen87 Thanks for the bug report... I think this should be fixed in #21342.