update BaseBackend to use a default coord_crs from the tms

[AndrewAnnex]

update BaseBackend to use a default coord_crs from the tms parameter. There is also the mosaic def's tms which could be used but it is not clear if should be assumed or not...

This was causing issues with custom non earth TMSs. This is a higher priority than #233 to get resolved.

[vincentsarago]

I'm not quite sure to see the issue. You can set you CRS when calling the method themself?

[AndrewAnnex]

@vincentsarago, forgive me if I don't explain the issue well here as it's fairly complicated but here's my current understanding:

I am working in the planetcantile project to define TMSs for other planetary bodies (Moon, Mars, etc) so that these can be used across titiler/morecantile/cogeo-mosaic for mosaic.json. Currently in Titiler the mosaicjson endpoints will default to WGS84 for the CRS here and cause Proj errors when attempting to convert between my non-earth CRSs/TMSs.

Without modifying Titiler directly I think it makes more sense to update cogeo-mosaic as each TMS has a explicit or implicitly discoverable geographic crs from it's CRS parameter. One can work around this by setting PROJ_IGNORE_CELESTIAL_BODY=YES, but that is a hack and may not always do the right thing depending on the ellipsoid (many of the planetary CRSs have ellipsoids with different flattenings/ no fattenings as the ellipsoids are defined with equal semi major/minor axes, but are not explicitly spherical CRS which are possible to define with WKT2...)

Again, If a person defines a mosaic.json file, a TMS is required, and so think it makes sense to always grab the appropriate geographic crs from the TMS object (which will know it implicitly from the CRS/geographic_crs of the tms) rather than assuming WGS84. assets_for_tile seems to do this already but for consistency and to avoid the exceptions I was seeing from titiler this PR attempts to make that consistent

On a side note, I am also debugging an issue in morecantile with the geographic_crs/rasterio_geographic_crs ending up as 4326 vs the intended geographic_crs depending on how the TMS is serialized/initialized. Although I haven't made enough progress on that to post an issue or pr yet.