add colormap endpoints

[vincentsarago]

ref #509

[vincentsarago]

TODO

• ask for feedback
• add tests

[JinIgarashi]

This new endpoint looks very useful. I would suggest to have a query param for number of classes at the endpoint of /colormap/{id}.
I can see current endpoint returns so many classes (44 No. what I can see in screenshot), but it would be nice if client side can request how many classes to be returned from titiler. I think number of classes parameter can be useful if want to use custom colormap to classify data with limited classes instead of linear legend.

Also, it might be useful if it can return color as hsl format in addition to rgba and hex formats. If color format is following maplibre style spec, it can be easier to adapt for maplibre/mapbox.

[vincentsarago]

@JinIgarashi thank for your feedback 🙏

(44 No. what I can see in screenshot)

in fact it returns 256 values, because all rio-tiler colormaps are composed of values between 0 and 255 (because that's how GDAL colormap are)

We could add a step parameter to only select few values but user would need to understand that for colormaps (e.g qualitative colormaps) this would give really weird results

[vincentsarago]

Also, it might be useful if it can return color as hsl format in addition to rgba and hex formats. If color format is following maplibre style spec, it can be easier to adapt for maplibre/mapbox.

Well the more I think about this, the more I think we should only return value as RGBA tuple, not event as HEX string. It seems quite trivial do transform the RGBA values to hex or hsl in client application instead of adding more complexity in the titiler endpoint

[vincentsarago]

This new endpoint looks very useful. I would suggest to have a query param for number of classes at the endpoint of /colormap/{id}.

same as #796 (comment), this would be pretty trivial to do in the client application directly instead of adding complexity in titiler endpoint IMO

[vincentsarago]

Q: we have the tilematrixet endpoints with a /tileMatrixSet prefix (defined by OGC), so should the colormap endpoints be prefixed with colorMaps (instead of colormaps as defined now)?

## This PR 

/colormaps
/colormaps/{colormapId}

## Proposed

/colorMaps
/colorMaps/{colormapId}