TimeIntervalCollection is a poor fit for very granular time ranges

This isn't exactly a bug, but I discovered some rough edges trying to work with the recently added time-dynamic WMS support. I brought it up in #6348 and Hannah asked me to open a new issue, so here it is.

I found [this sample data](http://mesonet.agron.iastate.edu/cgi-bin/wms/nexrad/n0q-t.cgi/) in a related ticket, I think. I'm working on a simple parser for the Capabilities document, so that I can advertise layers to the user and automatically configure the supported time parameters. To that end, I'm looking at the `` tag.

On this server, the value of that tag is `2011-02-16/2018-12-31/PT5M`. OK, let's set up a new `WebMapServiceImageryProvider` with `times = TimeIntervalCollection.fromISO8601({iso8601: str})`. This causes `parseDuration` to create 828000 `JulianDate`s, one for every 5 minutes over 7 years or so. Of course, the browser seems to hang for a long time while this is happening. But to my understanding, this is the only way of providing the `time` parameter value that should be sent, based on the simulation Clock's `currentTime`.

Is there another way to handle this? The WMS spec allows a single, simple string that they call a "range" or "periodic interval", to specify an effectively unlimited number of intervals (0001-01-01/9999-12-31/PT1M), so instantiating each interval described, all at once, seems inefficient. Is there a callback-based way of specifying intervals, so that we just describe the mechanism that maps an instant to an interval once? Are changes needed to the code to support this?

As an aside, I'm working on implementing a `TimeIntervalCollection` that doesn't actually store individual intervals but rather generates them on-demand based on a start/stop/period argument. I'll let you know how that goes.

Start with TimeIntervalCollection.fromISO8601 and the parseDuration path described in the issue, then inspect how WebMapServiceImageryProvider uses the selected interval to form its time parameter. Reproduce the delay with the linked WMS value and determine the intended API for granular ranges. Done requires an agreed design and tests showing that such ranges no longer require eagerly creating every interval.

Written by the indexing model from the issue text.