internal: don't use `accuracy = y_axis_breaks` in scales::label_number(), just let scales do its job

[francisbarton]

Suggest removing accuracy = y_axis_breaks where y_axis_breaks is NULL (the default). (NULL is the default value for the accuracy argument to scales::label_number())

[francisbarton]

I think this is a more general issue. Though still an open question on my part: does supplying accuracy = y_axis_breaks achieve anything on the primary y axis? It doesn't seem to work on the secondary y axis (as generated by the label_limits option) so I have a PR to remove it.

An initial trial on local data suggests that the package works perfectly well with leaving label_number() to use its internal algorithm to produce the most appropriate labels.

Can anyone provide a breaking case where this messes up the desired y axis?

I am leaving in one exception (for now / for discussion):

• where there is a percentage y-axis, the secondary axis (where requested) should have labels to an accuracy of 0.1 as this is very likely to be the most appropriate labelling format for mean and process limits. Formatting to 2dp is likely to be excessive.

[francisbarton]

This should be closed by #215 now (relevant commit: https://github.com/nhs-r-community/NHSRplotthedots/pull/215/commits/15ec95bc606b5b39fb95e0c0076a448aa4ddc083) I think.