Version selection requests are inefficient and cause multiple UI updates

[jrtcppv]

Currently a version change results in data being retrieved from the server regardless of whether it has already been retrieved. One request is sent per data type. When a response is received, the annotation data emits a freshData signal, potentially resulting in multiple intermingled UI updates, even for different versions if version changes are rapid and/or the requests are slow. The user is also able to continue interacting with the UI while the version change is active.

• Do not send requests for new data when it already is cached client side. AnnotationData should keep track of which versions have been retrieved, so it is requested at most once.
• Investigate whether freshData should be used with multiple types in one signal so UI updates are more efficient, and if so use Promise.all() so the UI is updated only once per version update.
• Lock out the UI with the loading spinner when version selections are in progress.

Thanks to @sbatchelder for bringing this to our attention.

[jrtcppv]

Because version specific data may change when one version is edited, this may require a cache invalidation scheme and be somewhat complicated. The UI lockout will be implemented as a hotfix and the caching scheme will be part of 1.4. Opened separate issue #1771 to track the UI lockout.

[jrtcppv]

It is possible that rather than using client side caching, we could leave the client unchanged and use cache control/ETag headers, relying on the browser to use disk cache instead of tracking this in the application. This would be the preferred approach. See #1772.

[jrtcppv]

Closed in favor of #1771 and #1772