feat(number): add parameter fractionDigits in float

[xDivisionByZerox]

Fixes #1596.

Since datatype.float and datatype.number now have significant differences compared to number.float I put the legacy implementation for the datatype functions directly into that module, without referencing the new implementation of the NumberModule.
This allows us to more freely change the new APIs without having a fear of breaking something in the legacy one.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d71bc47) 99.57% compared to head (0e9171c) 99.57%.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #1855      +/-   ##
==========================================
- Coverage   99.57%   99.57%   -0.01%     
==========================================
  Files        2807     2807              
  Lines      250411   250448      +37     
  Branches     1143     1149       +6     
==========================================
+ Hits       249349   249372      +23     
- Misses       1034     1048      +14     
  Partials       28       28              

Files	Coverage Δ
src/modules/finance/index.ts	100.00% <100.00%> (ø)
src/modules/location/index.ts	99.20% <100.00%> (ø)
src/modules/number/index.ts	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

[Shinigami92]

Adding the new parameter fractionDigits should have been an addition, not a replacement

Around 3 month ago, with many discussions and looking deeper into it, we finally came to the conclusion that we want to officially want to support this behavior to achieve "steps"
like 0.4 would result in 0.0, 0.4, 0.8, 1.2, ...
Using equivalent math with some logarithmic functions resulted in just painfully headaches and are not suitable for persons that are not trained in math

But as #1855 (comment) pointed to #1596 (comment) we want to XOR the parameter, so you will get a FakerError when you pass both parameters the same time as they are incompatible

[matthewmayer]

Would it be better to make stepped values a seperate method? so faker.number.float takes {max, min, precision} and e.g. faker.number.stepped takes {max, min, step}. I feel it's trying to stuff too much into one method.

[Shinigami92]

Would it be better to make stepped values a seperate method? so faker.number.float takes {max, min, precision} and e.g. faker.number.stepped takes {max, min, step}. I feel it's trying to stuff too much into one method.

I mark this for needs decision and we can discuss next meeting

[ST-DDT]

Would it be better to make stepped values a seperate method? so faker.number.float takes {max, min, precision} and e.g. faker.number.stepped takes {max, min, step}. I feel it's trying to stuff too much into one method.

I mark this for needs decision and we can discuss next meeting

Lets continue the discussion in the related issue to give our community the ability to input their suggestions so we can take them into consideration, when deciding this.

#1596

[ST-DDT]

Team decision

The proposal to move the precision/step logic into a different method has been rejected.
We will keep this precision/step option in the float method's single signature and document that the parameters are mutually exclusive.

[ST-DDT]

We will first refactor the method precision -> step.
Then continue with the fractionDigits PR.

[matthewmayer]

i think the documentation to the whole method could still use an overall rewrite, but as its not really specific to this parameter change i'll do that as a seperate PR after this is merged.