possible fix for always assuming WGS84

[AndrewAnnex]

This PR is slightly related to developmentseed/cogeo-mosaic#234 and developmentseed/cogeo-mosaic#233

Currently morecantile assumes WGS84 as the geographic_crs for most cases unless the user explicitly over-rides it via the api. However, saving TMSs doesn't always preserve the geographic_crs in json representations (it's not actually an allowed field from the TMS v2 spec, or rather not one explicitly encouraged) so depending on the situation there are cases when the the main CRS is defined for a non-earth celestial body, but the geographic_crs parameter will return 4326 depending on how the TMS is defined.

I think however the geographic crs is always discoverable directly from the CRS of the tms. If given a projected CRS, .geodetic_crs will always return a value, if given a GEOGCRS then the geographic_crs is essentially the same anyways. This PR (should) preserve the ability to allow explicit overrides, but will default to one appropriate to the CRS if not defined. I am not sure how robust this idea is though, so please throw stones at this/think of things I should test for

[AndrewAnnex]

@vincentsarago what's your current thinking for this pr given the other work in rio-tiler and etc?

[vincentsarago]

@AndrewAnnex I think we're good to merge, just need to update the changelog!

[vincentsarago]

so in fact I cannot Merge this PR 😬

I didn't realized but with #152 and this PR what you're trying to do is to ease the fact that you're storing _geographic_crs within the TMS document. Sadly this should not be authorized (because it breaks the spec)

[AndrewAnnex]

closing now that #158 is merged