Composable elevations interface

[eirizarry]

Child of #575

Establish a web-appropriate interface for composing elevations similar to WWJava's CompoundElevationModel. Use WorldWindAndroid's ElevationModel and ElevationCoverage interfaces as a baseline for this capability.

[pdavidc]

Here are points to consider from @AkeluX's brief review of WorldWindAndroid's new elevation interfaces:

Here are some initial thoughts. You
might have all this figured out already. In any case, I'm looking
forward to learning more about this new interface.

1. getTimestamp actually returns the max timestamp, i.e. allows to get
   the timestamp of the newest data in the model. It might be useful to
   get the timestamp of the oldest data in the model as well. I would
   therefore have getMaxTimestamp and getMinTimestamp.

2. The definition of hasCoverage(Sector) should be clarified between
   "has data for at least one point" and "has data for all the point of
   the sector". It seems that the former is what is implement, e.g. in
   TiledElevationCoverage. Would two methods be useful?

3. Something I don't understand, but also haven't had time to look
   deeper at, is what is the resolution of the result array and whether
   this has to be coordinated somehow between the various coverages.

4. The priority between the coverages seems to be the order of the
   ArrayList. The last item can override whatever it wants in the result
   array. I think this is fair enough, but we might want to offer the
   possibly to insert coverages at any place in the ArrayList, not only
   at the end with addCoverage and addAllCoverages. This would be the
   equivalent of insert in ArrayList.

[pdavidc]

@markpet49 I've had a chance to review the WorldWindAndroid elevation interfaces. Here are a few bullet points relating to what do in WebWorldWind:

• ElevationCoverage's displayName and enabled properties, like their Layer counterparts, provide essential functionality for applications.
• ElevationCoverage's user property interface are non-essential, as are the corresponding convenience methods on ElevationModel. These are part of a broader app convenience interface on layers and elevations, which we don't have in WebWorldWind yet.
• The timestamp methods are intended as a stopgap measure to control terrain regeneration. It's not a key part of the interface concept, though we need it as we have no alternatives at the moment.
• The hasCoverage methods turned out to be non-essential, and I removed them in an iteration after receiving @AkeluX's review.
• ElevationModel may make more sense as a self ordering set, rather than an ordered list. Applications often aren't able to discern the order in which elevations ought to appear. ElevationModel's methods ought to reflect whatever choice we make here.
• The getHeight methods may be more clear if they provide control over the desired resolution and indicate the resolution of the result array.