refactor(mersenne): rewrite internal mersenne

[Shinigami92]

Splitted from #1444

Changes:

• This changes the Mersenne module to be not anymore a class but a light weight function
• Also the code was rewritten so it is more easily maintainable
• Additionally seed does not throw anymore a FakerError on invalid input -> this has also the benefit of that mersenne is now fully decoupled from faker itself and could theoretically be swapped with a generator, but this could be done in another PR

[codecov]

Codecov Report

Merging #1447 (fd47e07) into next (4da3d5e) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head fd47e07 differs from pull request most recent head b415bf6. Consider uploading reports for the commit b415bf6 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #1447      +/-   ##
==========================================
- Coverage   99.63%   99.63%   -0.01%     
==========================================
  Files        2175     2175              
  Lines      237647   237613      -34     
  Branches     1021     1009      -12     
==========================================
- Hits       236785   236751      -34     
  Misses        841      841              
  Partials       21       21              

Impacted Files	Coverage Δ
src/faker.ts	95.04% <100.00%> (-0.05%)	⬇️
src/internal/mersenne/mersenne.ts	100.00% <100.00%> (ø)
src/modules/datatype/index.ts	99.12% <100.00%> (+<0.01%)	⬆️

[ST-DDT]

IMO we could remove the mersenneFn wrapper and integrate these functions in the faker class.
We would then ask faker for the next seeded value instead of accessing faker's private mersenne property and doing things with it.

[xDivisionByZerox]

IMO we could remove the mersenneFn wrapper and integrate these functions in the faker class. We would then ask faker for the next seeded value instead of accessing faker's private mersenne property and doing things with it.

I think that's the wrong way around. Currently, Faker is tightly coupled with the Mersenne generator. A way better approach would be to require a generator (probably denied from an interface) on construction, thus making the seed generation dependency injectable (follow the dependency inversion principle). This way I could build myself a Faker instance with the underlying generator I want.

interface SeedGenerator {
  next(): number;
}

class Faker {
  // properties
  constructor(options: {
    // current faker options
    generator: SeedGenerator; // could default to a mersenne implementation
  }) { 
    // initialization
  }
}

const instance = new Faker({
  ...defaultFakerOptions,
  generator: { next: () => 50 },
]);

In my eyes that's a much better approach since it allows for a higher level of abstraction and customization.