Fixes to the resolve colors function

[bbengfort]

This PR provides fixes to the resolve_colors function and adds a test suite to guard against regression. I've also reimplemented resolve_colors on the feature visualizers that had it commented out to use get_color_cycle instead.

This PR unblocks #321 -- however, a more extensive overhaul of color and color handling in YB is required. We have 4 different methodologies that are mixed and matched in kind of a strange fashion. More than that, Yellowbrick-specific requirements have emerged. Briefly, they are:

• We need discrete colors that are visually separate for classes
• We need continuous colors for regression values and heatmaps

Both of these requirements are specified by the target variable. Finally, we need helpers for the other utilities we use; but those can be largely handled with resolve_colors and get_color_cycle.

[lwgray]

You did way more than I expected. You took care of the logic flaw that was preventing the default color scheme from being selected. I see no problems with the rest of the code

[lwgray]

Great, you caught the logic here that was preventing usage of default color scheme.

[bbengfort]

Going to merge this PR even though tests are failing; it looks like something's up with Travis; will open a new branch to try to sort that out.