feat(number): move methods to new module

[xDivisionByZerox]

This move all number generators into their own (number) module.

Idea for this is from #805.

[xDivisionByZerox]

Currently, I have removed all functions that were moved to the number module. I guess that wasn't the best move from me since we should deprecate them in v8 and remove them in v9. Correct?

[codecov]

Codecov Report

Merging #1122 (237b81d) into next (0af0fff) will increase coverage by 0.00%.
The diff coverage is 98.59%.

Additional details and impacted files

@@           Coverage Diff            @@
##             next    #1122    +/-   ##
========================================
  Coverage   99.63%   99.64%            
========================================
  Files        2220     2221     +1     
  Lines      238957   239065   +108     
  Branches     1035     1045    +10     
========================================
+ Hits       238095   238209   +114     
+ Misses        841      835     -6     
  Partials       21       21            

Impacted Files	Coverage Δ
src/modules/image/providers/lorempixel.ts	91.30% <0.00%> (ø)
src/modules/internet/user-agent.ts	93.24% <86.20%> (+0.65%)	⬆️
src/faker.ts	95.08% <100.00%> (+0.03%)	⬆️
src/index.ts	100.00% <100.00%> (ø)
src/modules/color/index.ts	99.73% <100.00%> (-0.01%)	⬇️
src/modules/commerce/index.ts	100.00% <100.00%> (ø)
src/modules/datatype/index.ts	100.00% <100.00%> (+0.81%)	⬆️
src/modules/date/index.ts	99.13% <100.00%> (ø)
src/modules/finance/index.ts	100.00% <100.00%> (ø)
src/modules/git/index.ts	100.00% <100.00%> (ø)
... and 9 more

[xDivisionByZerox]

Suggestion from a discord user:

I would love to have a number.int, number.bigInt and something with IEEE 754

[Shinigami92]

BLOCKED: we cannot name the module Number as this is the JavaScript global Number constructor and we would run into the same issues as with _Date module (were we actually also want to find a better name for, like e.g. DateModule or Temporal)

If we name it NumberModule please first merge #932

[ST-DDT]

Correction
Log10(2.5)

... well, we have a problem there:

So beside that I absolutely do not understand this math magic you are doing with these log10s, it results in values greater then the requested max 👀

Math: 1 / x = 0.4 => x = 2.5 and 10 ** log10(x) = x

Range: The issue here is probably with number.int
It uses +1 to make max inclusive.

1.9 × 2.5 = 4.75
4.75 + 1 = 5.75 (5 as int)
5 / 2.5 = 2

So instead of adding one we might want to add a very small number and then round up.
Alternatively substract precision from max before passing it to int. Not sure whether that creates other issues.

[ST-DDT]

We might want to be more strict in number.int anyway and ceil min and floor max before checking and using it. Because then we would pass 5 to mersenne, but since it is exclusive we will only get 4 as max returned value => 4 / 2.5 = 1.6.
Not tested yet.

[ST-DDT]

Also since that math confuses even our own developers how about having both options?
Precision as used previously and decimal digits as used here?

[Shinigami92]

I ensured together with @ST-DDT that the tests / bugs are already there before this PR and so I extracted it to #1595 so we do not pollute this PR with fixing this bug.

[Shinigami92]

Due to the confusion with the log10 stuff, @ST-DDT and I decided for now to revert the parameter precision change from this PR.
But we will create a new issue to re-think about the change in another PR. (rename precision to fractionDigits)