Vertical level support for API

[fjugipe]

Description

After this pull request:

• The API is able to return the vertical level of observations in height above or below mean sea level in meters.
• Users are also able to filter data and locations based on vertical level
• vrs is defined with EPSG:5714

Features

• Return the vertical_extent of data using mean sea level
• Filter data with z query parameter on endpoints
• Filter data using 3D coords in endpoints where it is applicable

Note from EDR spec:
If a client request has a bbox value which includes height values and defines a z query parameter the z query parameter will be the definition of the requested height value

Refactors

• All periods to -> durations for consistency

Fixes

• levels and durations query parameter filtering with /items

Limitations

• Currently we have no good way of returning the vertical_extent on metadata pages or /locations
  • When camsl is moved to geo_point table in Issue 256 - move camsl to geo_point table #263 it should probably be returned with LocMetadata in GetLocsResponse
  • Also in GetExtentsResponse as vertical_extent
• /area now supports 3D polygon coordinates, but they are actually returns data in 3D flat polygons
• camsl defaults to 0 if it is not provided when ingesting data to the system, so observations without that metadata are considered as being in mean sea level

closes #284

[fjugipe]

Opened this as a draft for dicussion if #263 should be merged to this first and then to main together.

[github-actions]

Title	Coverage	Tests	Skipped	Failures	Errors	Time
API Unit Tests		43	0 💤	0 ❌	0 🔥	1.566s ⏱️
Ingest Unit Tests		16	0 💤	0 ❌	0 🔥	2.516s ⏱️