Move choropleth to class

[Conengmo]

Closes #981.

I have been meaning to do this for a while now :) Moving the Map.choropleth() method to its own class, so it's similar to all other folium types. This is not a super important change, but I think it makes our code base more consistent, which is good for developers, and makes our API more consistent, which is good for users.

I haven't changed any functionality, except:

• Choropleth accepts show, overlay and control arguments like other layer types.
• Made Choropleth a subclass of FeatureGroup and tweaked the rendering.
• Removed the reset option, since it didn't do anything.
• Map.choropleth method still works but raises a FutureWarning

Note about ColorMap:
It needs Map as its parent, or we'd have to change branca. Also it cannot be included in the FeatureGroup, so it cannot be toggled in layer control.

Links to the changed notebooks:
Quickstart.ipynb
GeoJSON_and_choropleth.ipynb

I made sure the tests still work and updated the example notebooks. Didn't add a line to the changelog yet.

@ocefpaf or @jtbaker, want to review this one?

[ocefpaf]

The long term goal was to remove choropleth entirely and leave only the GeoJson class. I guess that people rely on it so much that we are promoting it to a first class citizen in folium again 😄

[Conengmo]

Thanks for the review and merge @ocefpaf. I agree it's a bit of an outlier but it seems much used given the number of issues we get on it.

By the way, the commits weren't squashed. Did the default setting changed? I'm not paying much attention to my commits since I thought we're squashing .

[ocefpaf]

Did the default setting changed?

Probably. I did not noticed that :-/

I'm not paying much attention to my commits since I thought we're squashing .

Same here. Not a big deal though. I'll take a better look next time before merging.