Configurable qualitative color scales

[cpsievert]

Closes #3826 by:

1. Allowing control over discrete colour scaling defaults (i.e., scale_[fill/colour]_discrete()) through a new type argument, which defaults toggplot2.discrete.[fill/colour] options.
2. Adding the ability to supply a collection of color codes to type and using those codes if (and only if) there are more codes than levels. In addition to a character vector, you can also supply a list of vectors to type and it will choose the minimum length vector that can support the number of levels to encode, which provides a convenient way to switch the default palette based on the number of levels (see examples below).
   3. Having type default to a colour-blind safe colour palette, such as Okabe-Ito. This will lead to 'breaking' changes, but those who wish to have the old behavior can do: options(ggplot2.discrete.fill = scale_fill_hue, ggplot2.discrete.colour = scale_colour_hue)

(UPDATE: this PR won't change the default, but a future major release likely will)

Examples

library(ggplot2)
# Template function for creating densities grouped by a variable
cty_by_var <- function(var) {
  ggplot(mpg, aes(cty, colour = factor({{var}}), fill = factor({{var}}))) +
    geom_density(alpha = 0.2)
}

# Define custom palettes for when there are 1-2, 3, or 4-6 levels
opts <- options(
  ggplot2.discrete.fill = list(
    c("skyblue", "orange"),
    RColorBrewer::brewer.pal(3, "Set2"),
    RColorBrewer::brewer.pal(6, "Accent")
  )
)
# Two levels
cty_by_var(year)

# Three levels (Set2)
cty_by_var(drv)

# Five levels (Accent)
cty_by_var(fl)
#> Warning: Groups with fewer than two data points have been dropped.
#> Warning in max(ids, na.rm = TRUE): no non-missing arguments to max; returning -
#> Inf

# Seven levels (scale_fill_hue)
cty_by_var(class)

options(opts)

^{Created on 2020-02-24 by the reprex package (v0.3.0)}

TODO

• Unit tests (visual and scale_[fill/colour]_qualitative())

[thomasp85]

@clauswilke and @cpsievert where are we on this? If we want to have this in 3.3.1 we will need to get this finished off in a way where it is non-breaking (i.e. doesn't default to okabe-ito, but the regular behaviour). I'm fine with having a breaking change in this for the release after that.

Should we add the infrastructure in 3.3.1 or just wait for the whole PR until after the patch release?

[clauswilke]

I think it's in @cpsievert's court to finish this off. He had indicated a one-line change that would make this non-breaking, but I think this change hasn't been applied yet: https://twitter.com/cpsievert/status/1255585845915955200?s=20

@cpsievert Could you commit this change and resolve the conflicts etc? And I'm still not sure whether this comment (#3826 (comment)) needs further addressing.

[cpsievert]

Ok, this should be ready for a closer look now.

Also, @clauswilke, I asked Hadley about that comment you've linked to and he said he can't recall what he was talking about