deprecate quick_collection in favor of more idiomatic geo_types::GeometryCollection::try_from(geojson)?

[michaelkirk]

Our current docs advertise quick_collection as the royal road to getting a geo_types::GeometryCollection from a &GeoJson

//! [...] using the [`quick_collection`](fn.quick_collection.html) function to
//! parse [`GeoJson`](enum.GeoJson.html) objects into
//! a [`geo_types::GeometryCollection`](../geo_types/struct.GeometryCollection.html).

We also have:

impl<T> TryFrom<GeoJson> for geo_types::Geometry<T> 

Which is almost but not quite redundant.

1. it consumes the GeoJson
2. it deals with Geometry, not GeometryCollection.

Would people support deprecating quick_collection and instead adding and promoting the use of GeometryCollection::try_from, or is there a reason to continue promoting quick_collection?

It's been around for a while and promoted as "the" way to get geo-types from geojson, so if we did deprecate it, we'd probably want to leave it around for a long while.

The advantage of being idiomatic is that hopefully it's something that people with a little rust experience would look for / expect.

[urschrei]

I think that when I stole the quick_collection idea from @lelongg we didn't have GeometryCollection::TryFrom, so I'm fine with the change. I was thinking earlier that we slightly re-write the README to address what I think are the most common use cases:

1. We lead with conversions to / from GeometryCollection and FeatureCollection;
2. We show the existing examples of the more granular / performant conversion and processing examples;
3. We detail the structure of the library (also existing).