Add ContinuousColor and OrdinalColor columns

[nrbgt]

Checklist

• the PR target is correct
  • main for releases, docs-only fixes and post-release hot-fixes
  • dev for everything else
• ran doit lint locally

References

• fixes Native continuous colorscales/colormaps #83
• blocked by Add DodoSource #68

Code changes

• adds OrdinalColor and ContinuousColor
  • each has a Scheme enum with compatible types
  • ordinal can be overloaded with custom colors in range (not really documented)
• unit tests
• robot tests
• docs

User-facing changes

• users can now add relatively flexible color scales based on column values
  • domain values have to be known up-front, generally

Screens

note	shot
manual
continuous and ordinal
strawman

Backwards-incompatible changes

• n/a

[github-actions]

Try it on ⬅️ ReadTheDocs or Binder ➡️

[nrbgt]

Going to relock here, then dig into tests. Ideally, we'd also hit the categorical ones as well.

[sanbales]

Working great! No real concerns, only one minor nitpick comment which I'd be happy to have it ignored.

[sanbales]

This is nitpicking to the n-th degree, so apologies in advance, but should this be CategoricalColor (or DiscreteColor)?

My understanding is that ordinal is for discrete values that have an order (e.g., number of wheels: [1, 2, 4]), but categorical is for those things that don't have an order, e.g., car manufacturer: ["Honda", "GM", "Ford"].

I'm confused by the d3-scale-chromatic API though, because in their docs they say these scales are Categorical , but in the code they are under scaleOrdinal?

Again, apologies for the nitpicking...

[nrbgt]

at the end of the day, things have to be in an order, both on the input and output side.

we're using that for e.g. domain: ["a",false, 3] and range: [red, yellow, blue] would get something, even though the values in either side of the transfer function can't really be compared.

[nrbgt]

558a12e adds a manual scale example