Default pretty_num() behaviour has changed

[cjrace]

Describe the bug

As of v0.6.0 pretty_num() now forces in two decimal places by default, when before it used to round to 0 dp.

How to reproduce

Steps to reproduce the behaviour:

1. Run dfeR::pretty_num(2024)
2. You'll see you now get 2,024.00

Then checkout the previous version of the package:

In a terminal run git checkout tags/v0.5.1 (the previous version)

Then run:

devtools::load_all(".")
dfeR::pretty_num(2024)

You'll see on the older version you get "2,024" as the result.

Expected behaviour

I'd have expected the behaviour to stay consistent through the additions. So I'd expect dfeR::pretty_num(2024) to still return "2,024".

Screenshots

An example where I spotted this - we have some tooltips in a dashboard that used to be rounded to 0 dp, but now have 2 dp forced in afterwards after updating the package, in itself not the end of the world, but slightly odd that we've managed to change the behaviour unexpectedly. This kind of thing could easily be missed by others when updating the package and break what they'd intended to happen.

Additional context

1. I think we should make the default behaviour have 0 decimal places to match what existed before
2. We should review our test coverage to make sure we're happy we have enough to prevent this kind of breaking change moving forwards