Fix stalling on discontinuity with audio track

[robwalch]

This PR will...

Improve the handling of audio-stream-controller waitingFrag by:

• Always removing the waiting fragment from the fragment tracker when clearing it before it's appended
• Use fragment-finders fragmentWithinToleranceTest in audio-stream-controller
• Parse waiting fragment when fragment cc initPTS is known (so that we establish sync with video)
• Drop waiting fragment when:
  • video cc has changed since waiting fragment was set but not to the cc needed to parse waiting cc
  • The waiting fragment is no longer the audio fragment that needs to be buffered

Why is this Pull Request needed?

The audio-stream-controller got stuck on discontinuities for because the waiting was not used when it should be and it's status was not managed correctly:

1. videoTrackCC is only updated once initPTS[waitingFragCC] is available, which caused the waiting fragment to be cleared before onInitPtsFound could fire. Using videoTrackCC to see if we still needed the waiting fragment simply did not work.
2. waitingFrag was set to null in several places, requiring that fragment to be reloaded, but without clearing it's status from the fragment-tracker, so it would not reload.

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

Resolves issues:

Resolved #2913, #2545
Related to #2832

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

We're actually waiting for videoTrackCC to increment so this is not a good check.

[robwalch]

videoTrackCC is set in onInitPTS so I don't see how this check would ever be true.

[robwalch]

What we really want to know here is stream-controller current fragment - which fragment cc and start time is being loaded and whether that is close to or precedes our waiting fragment without any audio buffer gaps in between.