Check that breakpoint split view is ready before fetching to avoid crash/large data fetching

[cmdcolin]

Background - prehistory

The breakpoint split view, for better or worse, fetches features independently of the tracks

This is because the tracks don't have full info about the features that they contain, because this is slow due to serialization of data over webworker

Background - this issue

The breakpoint split view calls CoreGetFeatures independently of the tracks. However, it doesn't check if it is appropriate to call getFeatures (e.g. if it is looking at too large an area)

This can cause it to trigger very large data downloads accidentally in some cases, and this came up when re-navigating breakpoint split views

This fix

This PR fixes it by checking for the track.displays[0] being not not ready. This may not be a complete solution even in itself yet, because it only checks the flag on the first instance of the track e.g. not both levels of the breakpoint split view

Fixes #5026

Random background

We use the term notReady instead of ready because if a track sets the ready flag to undefined, that does not necessarily mean it is not ready even though that is falsy...we try to look for genuine signals from tracks who define the concept of them being not ready but looking for notReady true, which avoids having to reason about ready:undefined being not ready or not