Improve stats recording for progressive streaming

[johnBartos]

This PR will...

• Refactor stats class:
  • Flat properties broken into loading, parsing, buffering buckets
  • Each bucket records start, end
  • loading, buffering buckets include a first property, which records when the the first chunk completed that operation
• Introduce ChunkMetadata object
  • Provides a way to associate progressive chunks with stats
  • Replaces transmuxIdentifier
• Introduce chunk-specific stat objects on the ChunkMetadata object
  • Records time to transmux, including time spent in the worker queue
  • Records time to buffer, including time spent in the buffering operation queue, for both audio, video, and audiovideo buffers
• Implements a new PerformanceMonitor module:
  • Currently logs all fragment stats on FRAG_BUFFERED, which used to be emitted in the abr-controller
• Pass the frag reference in the BUFFER_APPENDING payload to allow the frag.stats.buffering.first stat to be recorded
• Improve various TS things
• Update basic demo page with the new BBB link

Why is this Pull Request needed?

So that we can accurately measure stats while progressively streaming. These stats will help us assess the performance impact on progressive and tune it to be as good as possible

Are there any points in the code the reviewer needs to double check?

No

Resolves issues:

JW8-10153

[robwalch]

Looks good. The only code in commercial that will be affected by the breaking change is in adaptive-display.js where we get a running load time for current segment:

var loadTime = stats ? ((stats.tbuffered || stats.tload) - stats.trequest) : 0;
See test/hls/adaptive-display.html

[jwplayer-robot]

⚠️ Build for commit 0c4b549 is unstable.
🏗️ jwplayer/hls.js build 278 SUCCESS
🏗️ jwplayer-commercial build 23149 SUCCESS
🥒.js Allure Report UNSTABLE
🥒 Allure Report UNSTABLE
🍆 Squash PR build 23149
🍆 Squash HLSJS Suite 23149