Refine logarithmic scaling / tick generation

[kurkle]

Fix: #7332

This changes the log scale to generate ticks based on the data range. Also generates more ticks (3, 15).

Random example data: [300, 2000, 10000, 800000, 80, 200000, 40]:
(master)

(pr)

Another: data: [30070000, 30008000, 30400000, 31000000, 30020000, 30000900, 30000700]
(master)

(pr)

data: [80000, 3008000, 3400000, 3100000, 3020000, 3000900, 6000000], autoSkip: false
(master)

(pr)

data: [31.16, 31.46, 32.02, 30.08, 29.47, 27.46, 29.05, 29.09, 31.09, 28.41]
(master)

(pr)

[kurkle]

Filename	Size	Change
dist/chart.esm.js	70.6 kB	+254 B (0%)
dist/chart.js	89.7 kB	+254 B (0%)
dist/chart.min.js	63.9 kB	+167 B (0%)

[benmccann]

The screenshots for the PR definitely look better than the screenshots for master!

I had a branch to fix this here: https://github.com/benmccann/Chart.js/tree/log-scale-ticks. I'd be curious how it compares on these datasets. There are a couple things in the screenshots above that I think still have a bit of room for improvement. I'd gotten things working pretty well, but never had time to update all the tests to match the new implementation

[kurkle]

@benmccann my implementation was initially very similar to yours, excluding those +/-5% adjustments that probably do not work well in all cases.

I agree there is still room for improvement.

This might not be desirable behavior (generating 10 ticks between 27 and 28):

[etimberg]

Code and screenshots look fine. Concerned that this might be too breaking

[kurkle]

Concerned that this might be too breaking

I share the concern. Maybe this should be delayed to v4.

[benmccann]

This PR does change the UI a fair amount, but I'm not really sure I'd consider it breaking since it doesn't change the API at all

[kurkle]

@etimberg @LeeLenaleee @benmccann how about merging this?