Respect scale and nonlinear values in PlotUtils cgrads

[asinghvi17]

Description

Fixes #1977

Essentially, reverts a change from #1723.

I'd like to release a v0.16.7 with this change as well. since it is somewhat serious.

Before

(note how they are all the same)

After

Type of change

Delete options that do not apply:

• Bug fix (non-breaking change which fixes an issue)

Checklist

• Added an entry in NEWS.md (for new features and breaking changes)
• Added reference image tests for new plotting functions, recipes, visual options, etc.

[MakieBot]

Compile Times benchmark

Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt.

using time

master:  9.20 < 9.26 > 9.41, 0.07+-
pr:      9.16 < 9.27 > 9.38, 0.08+-
speedup: 0.99 < 1.00 > 1.01, 0.01+-
median:  +0.17% => invariant

This PR does not change the using time.

ttfp time

master   25.01 < 25.19 > 25.40, 0.12+-
pr       24.90 < 25.16 > 25.39, 0.15+-
speedup: 1.00 < 1.00 > 1.00, 0.00+-
median:  -0.10% => invariant

This PR does not change the ttfp time.

[asinghvi17]

CI errors are because of a missing reference image for the new test.

[SimonDanisch]

Alright, I took a deep dive to make sure this is correct now... I guess I misunderstood cgrad a bit when I made that change.
I added some more tests to make sure we do the right thing now

[asinghvi17]

Thanks for taking this forward!

On a side note - I wonder if returning a Sampler might be a more efficient solution? Colormaps with intentionally tiny variations, like those with e.g. scale = x -> log(100, x), might then be somewhat misrepresented.

I'm not sure whether [W]GLMakie will accept Sampler (from colorsampler.jl) as a native type but I think something like that might be a somewhat more elegant solution to the problem.

[SimonDanisch]

Yeah we need a refactor of the whole colormap pipeline and then make sure that wherever colormaps are used, they work exactly the same without hacks like we have here