New Scale syntax and implementation

[thomasp85]

Fix #16

This PR implements the discussed scale syntax which is roughly (for now)

SCALE <TYPE> <aesthetic> FROM <input-range> TO <output-domain> VIA <transform>
    SETTING param => value

TYPE can be one of:

• CONTINUOUS
• DISCRETE
• BINNED
• DATE
• DATETIME

and will be inferred from the data if missing. Not all data can be scaled with all types and will result in an error if attempted.

Valid params is at least:

• oob: How should values outside the range be handled
• expand: How/if should the guide expand outside the given range

Still undecided is the fate of guides. Should they be a SETTING setting in which case breaks also end up there, or should guide expand to its own clause with more possibilities

TODO:

• Update syntax
• Inference of TYPE
• Inference of range
• Allow null in continuous range to let either end be determined from data, e.g. FROM [0, null] to set the lower end to zero and the upper end to the maximum value in the mapped data
• Default output domains for aesthetic+TYPE
• Scale expansion
• oob handling
• Binning (might have to be kicked down the road)
• Restructure of Scale to a trait based setup (maybe)
• The whole guide + breaks conundrum
• Break labels
• Correct legends for binned scales

[teunbrand]

There is currently a bit of mixed used between input/output range and domain. It'd be good if we were consistent about this. I find 'domain' more confusing than output range.

What should we do about the legacy scales?
Are scale transformations handled at the writer?

[thomasp85]

There is no such thing as "legacy scales" during this cycle. Everything will be updated to the new architecture (don't know if that was what you meant). As for transformations that is still undecided. Hopefully it will happen before the writer, using polars