Reduce redundancy related to climatic indicators

[ricardogsilva]

In the current version of the system we need to provide multiple details about the climatic indicator which is being used by both:

• forecast-related coverages
• historical coverages
• station observations

Information related to a climatic indicator is:

• display_name
• description
• unit
• data precision
• legend-related details (palette name, min/max values)
• etc.

This information is currently duplicated in many different places (as instances of ConfigurationParameter, and as properties of CoverageConfiguration).

Let's refactor into a way that has less duplication.

[ricardogsilva]

After some thought, my current plan is to implement a ClimaticIdentifier model, which will have the following properties:

• name: str
• measure_type: MeasureType
• aggregation_period: AggregationPeriod
• display_name_english: str
• display_name_italian: str
• description_english: str
• description_italian: str
• unit_english: str
• unit_italian: str
• palette: str
• color_scale_min: float
• color_scale_max: float
• data_precision: int
• sort_order: int

This new model will have a 1:N relationship with CoverageConfiguration. I also plan to use it in the future in the station observations. This will result in:

• Less properties to be duplicated in each CoverageConfiguration
• Shorter coverage identifiers
• No need to have ConfigurationParameter instances describing climatological_variable, aggregation_period, measure_type, as these all become properties of the climatic indicator
• Eventually there will be no need for the awkardly-named Variable model,
• the new types MeasureType and AggregationPeriod can be implemented as enumswhich is used in the station observations sections