Organization of parsing logic

[karimbahgat]

@djhoese wrote:

I also feel like the way I would have done this is put the crs-specific parsing logic in to a crs module along side the CRS classes that get returned. If the interface is clean enough you could even do a class method from_proj4 on the CRS class that parses a proj4 str/dict and returns the proper CRS class. That is how I would do it, doesn't mean the way it is done now is wrong or bad. Just being opinionated 😉 and laying out the options I see available.
...
After sleeping on it I think the from_proj classmethod is maybe a bad idea given the amount of logic that exists in the parsing code.

About where to place the parsing logic, I agree that putting the logic alongside each individual component would keep things nicely grouped together. It could be something to look at in the future, but for reasons of time and effort I think we'll stick to the current scheme for now, plus I think my reason for originally doing all the logic in one "global" function is that sometimes you need to know the values of other parameters in order to correctly parse a parameter.