Decide on blessed conversion implementation or API

[evetion]

Related to #2.

With JuliaGeo/Proj.jl#74 Proj could also convert between GFT.CRS instances. Proj itself is a lighter dependency than ArchGDAL, and is actually what GDAL itself uses (indirectly).

[rafaqz]

A counter argument is that the main current use of this conversion is in ArchGDAL reproject (from Rasters and GeoDataframes). I would prefer no to add a Proj dep where we already have ArchGDAL. You would have to add it to GeoDataframes.jl as well.

I think we just need to make a backend interface so ArchGDAL also still works. We can use the Val{:ArchGDAL} dispatch trick.

[asinghvi17]

If we're switching reproject to Proj, can we also switch this now? Or implement the backend interface, though I'm not sure how that might work.

[rafaqz]

Let's switch.

Ugh it may be a bit of a pain with versioning... What happens with compilation when both packages are doing the same type piracy.

DiskArrays also has Rasters stuck on old GDAL via CommonDataModel so we actually can't get away from it easily.

[asinghvi17]

The plan for switching to Proj might be:

• ArchGDAL takes a dep on Proj and releases a minor version, constraining the Proj version to v1.8 or less.
• Proj releases a v1.9 that has specific convert methods for each GFT CRS type, so that it always overrides the ArchGDAL generic convert method
• ArchGDAL releases a breaking release that drops its type piracy, and upgrades the Proj compat to "1.9"
• At some point in the future, we consolidate the Proj methods into a single method, and drop the ArchGDAL compat requirement.

[visr]

Haven't thought about it much, but looks good to me, except that Proj 1.7 should be replaced by 1.8 and 1.8 by 1.9. I just tagged 1.8 which has the last PROJ build, and am rebuilding GDAL to be compatible with that last build.