In this change, we bumped relevant dependencies to stick to `php:^7.3` as minimum
supported `php` version (since `7.2` is EOL'd and no longer covered by security fixes).

To do that, we upgraded all dependencies, upgraded spec files to comply with newest phpspec.

This currently means that we have a few broken scenarios and failures:

```
----  failed examples

        Money/Parser/DecimalMoneyParser
  47  ✘ throws an exception when money includes currency symbol
        expected exception of class "Money\Exception\ParserExc...", but got
        [exc:PhpSpec\Exception\Example\ErrorException("16384: Passing a currency as string is deprecated since 3.1 and
        will be removed in 4.0. Please pass a Money\Currency instance instead. in
        /home/ocramius/Documents/moneyphp/money/src/Parser/DecimalMoneyParser.php line 50")].

        Money/Parser/DecimalMoneyParser
  52  ✘ throws an exception when money is not a valid decimal
        expected exception of class "Money\Exception\ParserExc...", but got
        [exc:PhpSpec\Exception\Example\ErrorException("16384: Passing a currency as string is deprecated since 3.1 and
        will be removed in 4.0. Please pass a Money\Currency instance instead. in
        /home/ocramius/Documents/moneyphp/money/src/Parser/DecimalMoneyParser.php line 50")].

----  broken examples

        Money/Exchange/ExchangerExchange
  27  ! is initializable
        could not reflect class Exchanger\Exchanger as it is marked final.

        Money/Exchange/ExchangerExchange
  32  ! is an exchange
        could not reflect class Exchanger\Exchanger as it is marked final.

        Money/Exchange/ExchangerExchange
  37  ! exchanges currencies
        could not reflect class Exchanger\Exchanger as it is marked final.

        Money/Exchange/ExchangerExchange
  53  ! throws an exception when cannot exchange currencies
        could not reflect class Exchanger\Exchanger as it is marked final.

        Money/Parser/DecimalMoneyParser
  31  ! parses money
        16384: Passing a currency as string is deprecated since 3.1 and will be removed in 4.0. Please pass a Money\Currency
        instance instead. in /home/ocramius/Documents/moneyphp/money/src/Parser/DecimalMoneyParser.php line 50

29 specs
185 examples (178 passed, 2 failed, 5 broken)
146ms
```

…sed, then they should be raised

No suppressing them, since otherwise they effectively go unnoticed. Having a suppressed `trigger_error()` means
that only side-effects get run, instead of proper exception conversion.

… number operations

These benchmarks cover the "most used" functionality of `Money`, and should highlight any
computational complexity overhead.

…nd `Money::avg()`

…umber internals

…and becoming unusable later on

…n internal functions

Overall really hard to tell if the results are legit, but there are some improvements:

```
❯ php -dopcache.enable_cli=1 ./vendor/bin/phpbench run --ref=original --retry-threshold=5 --iterations=10
PHPBench @git_tag@ running benchmarks...
with configuration file: /home/ocramius/Documents/moneyphp/money/phpbench.json
with PHP version 8.0.3, xdebug ❌, opcache ✔

\Benchmark\Money\NumberInstantiationBench

    benchConstructorWithZeroIntegerAmount...R1 I0 - [Mo575.630μs vs Mo591.581μs] -2.70% (±2.20%)
    benchConstructorWithPositiveIntegerAmou.R7 I9 - [Mo551.930μs vs Mo550.683μs] +0.23% (±3.02%)
    benchConstructorWithNegativeIntegerAmou.R1 I1 - [Mo554.108μs vs Mo580.812μs] -4.60% (±1.80%)
    benchConstructorWithZeroAndFractionalAm.R1 I3 - [Mo543.759μs vs Mo595.014μs] -8.61% (±1.77%)
    benchConstructorWithFractionalAmount....R1 I1 - [Mo589.360μs vs Mo611.898μs] -3.68% (±1.92%)
    benchConstructorWithNegativeFractionalA.R1 I0 - [Mo573.149μs vs Mo580.123μs] -1.20% (±2.22%)

\Benchmark\Money\MoneyOperationBench

    benchAdd................................R1 I6 - [Mo999.123μs vs Mo987.689μs] +1.16% (±2.42%)
    benchSubtract...........................R1 I9 - [Mo985.683μs vs Mo936.192μs] +5.29% (±1.70%)
    benchMultiply...........................R1 I7 - [Mo1.003ms vs Mo1.057ms] -5.11% (±2.00%)
    benchDivide.............................R1 I9 - [Mo946.427μs vs Mo1.031ms] -8.19% (±3.11%)
    benchRatioOf............................R1 I2 - [Mo985.380μs vs Mo989.503μs] -0.42% (±2.17%)
    benchMod................................R2 I5 - [Mo391.671μs vs Mo401.023μs] -2.33% (±2.37%)
    benchIsSameCurrency.....................R1 I4 - [Mo2.000μs vs Mo2.000μs] 0.00% (±0.00%)
    benchIsZero.............................R10 I9 - [Mo384.644μs vs Mo426.642μs] -9.84% (±1.56%)
    benchAbsolute...........................R2 I9 - [Mo423.309μs vs Mo396.644μs] +6.72% (±2.35%)
    benchNegative...........................R6 I9 - [Mo981.397μs vs Mo983.110μs] -0.17% (±2.55%)
    benchIsPositive.........................R3 I9 - [Mo386.301μs vs Mo392.182μs] -1.50% (±2.37%)
    benchCompare............................R7 I8 - [Mo387.603μs vs Mo397.301μs] -2.44% (±3.22%)
    benchLessThan...........................R3 I9 - [Mo407.575μs vs Mo390.164μs] +4.46% (±2.31%)
    benchLessThanOrEqual....................R1 I9 - [Mo425.425μs vs Mo430.164μs] -1.10% (±1.34%)
    benchEquals.............................R1 I7 - [Mo2.000μs vs Mo3.000μs] -33.33% (±0.00%)
    benchGreaterThan........................R1 I7 - [Mo390.366μs vs Mo390.450μs] -0.02% (±2.10%)
    benchGreaterThanOrEqual.................R2 I9 - [Mo412.262μs vs Mo411.738μs] +0.13% (±1.99%)

\Benchmark\Money\MoneyInstantiationBench

    benchConstructorWithZeroIntegerAmount...R2 I4 - [Mo904.501μs vs Mo898.483μs] +0.67% (±2.20%)
    benchConstructorWithPositiveIntegerAmou.R1 I8 - [Mo915.419μs vs Mo937.671μs] -2.37% (±2.11%)
    benchConstructorWithNegativeIntegerAmou.R1 I5 - [Mo896.722μs vs Mo909.286μs] -1.38% (±1.30%)
    benchConstructorWithZeroStringAmount....R2 I4 - [Mo908.315μs vs Mo933.039μs] -2.65% (±2.32%)
    benchConstructorWithPositiveStringAmoun.R1 I8 - [Mo890.975μs vs Mo857.589μs] +3.89% (±1.99%)
    benchConstructorWithNegativeStringAmoun.R1 I2 - [Mo858.750μs vs Mo904.536μs] -5.06% (±2.54%)

Subjects: 29, Assertions: 0, Failures: 0, Errors: 0
```

… removing useless test related to that

…Calculator()` all the time

This is a minimal improvement on a very hot execution path

…ultiply()` and `#divide()`

Also here, no noticeable improvements other than a massive jump in `benchRatioOf`:

```
❯ php -dopcache.enable_cli=1 ./vendor/bin/phpbench run --ref=original --retry-threshold=5 --iterations=10
PHPBench @git_tag@ running benchmarks...
with configuration file: /home/ocramius/Documents/moneyphp/money/phpbench.json
with PHP version 8.0.3, xdebug ❌, opcache ✔

\Benchmark\Money\NumberInstantiationBench

    benchConstructorWithZeroIntegerAmount...R1 I0 - [Mo569.571μs vs Mo591.581μs] -3.72% (±1.94%)
    benchConstructorWithPositiveIntegerAmou.R2 I8 - [Mo599.841μs vs Mo550.683μs] +8.93% (±2.41%)
    benchConstructorWithNegativeIntegerAmou.R1 I4 - [Mo621.906μs vs Mo580.812μs] +7.08% (±2.40%)
    benchConstructorWithZeroAndFractionalAm.R1 I9 - [Mo570.344μs vs Mo595.014μs] -4.15% (±2.62%)
    benchConstructorWithFractionalAmount....R2 I3 - [Mo600.387μs vs Mo611.898μs] -1.88% (±2.04%)
    benchConstructorWithNegativeFractionalA.R1 I2 - [Mo590.276μs vs Mo580.123μs] +1.75% (±1.99%)

\Benchmark\Money\MoneyOperationBench

    benchAdd................................R1 I3 - [Mo999.916μs vs Mo987.689μs] +1.24% (±1.97%)
    benchSubtract...........................R1 I9 - [Mo924.575μs vs Mo936.192μs] -1.24% (±2.18%)
    benchMultiply...........................R3 I8 - [Mo992.857μs vs Mo1.057ms] -6.09% (±2.46%)
    benchDivide.............................R1 I1 - [Mo1.015ms vs Mo1.031ms] -1.54% (±2.58%)
    benchRatioOf............................R5 I8 - [Mo381.761μs vs Mo989.503μs] -61.42% (±1.89%)
    benchMod................................R1 I9 - [Mo396.292μs vs Mo401.023μs] -1.18% (±2.16%)
    benchIsSameCurrency.....................R2 I8 - [Mo4.000μs vs Mo2.000μs] +100.00% (±0.00%)
    benchIsZero.............................R1 I3 - [Mo393.902μs vs Mo426.642μs] -7.67% (±1.72%)
    benchAbsolute...........................R1 I4 - [Mo379.667μs vs Mo396.644μs] -4.28% (±2.79%)
    benchNegative...........................R1 I3 - [Mo979.540μs vs Mo983.110μs] -0.36% (±2.10%)
    benchIsPositive.........................R1 I4 - [Mo408.442μs vs Mo392.182μs] +4.15% (±2.21%)
    benchCompare............................R1 I8 - [Mo381.159μs vs Mo397.301μs] -4.06% (±1.87%)
    benchLessThan...........................R1 I6 - [Mo391.462μs vs Mo390.164μs] +0.33% (±1.71%)
    benchLessThanOrEqual....................R4 I6 - [Mo416.380μs vs Mo430.164μs] -3.20% (±2.67%)
    benchEquals.............................R3 I4 - [Mo4.000μs vs Mo3.000μs] +33.33% (±0.00%)
    benchGreaterThan........................R1 I5 - [Mo382.789μs vs Mo390.450μs] -1.96% (±1.71%)
    benchGreaterThanOrEqual.................R1 I1 - [Mo379.530μs vs Mo411.738μs] -7.82% (±1.33%)

\Benchmark\Money\MoneyInstantiationBench

    benchConstructorWithZeroIntegerAmount...R2 I9 - [Mo945.877μs vs Mo898.483μs] +5.27% (±2.50%)
    benchConstructorWithPositiveIntegerAmou.R1 I7 - [Mo887.787μs vs Mo937.671μs] -5.32% (±2.63%)
    benchConstructorWithNegativeIntegerAmou.R3 I7 - [Mo958.738μs vs Mo909.286μs] +5.44% (±2.60%)
    benchConstructorWithZeroStringAmount....R1 I0 - [Mo954.548μs vs Mo933.039μs] +2.31% (±2.40%)
    benchConstructorWithPositiveStringAmoun.R3 I9 - [Mo931.642μs vs Mo857.589μs] +8.64% (±2.42%)
    benchConstructorWithNegativeStringAmoun.R1 I2 - [Mo943.121μs vs Mo904.536μs] +4.27% (±1.88%)

Subjects: 29, Assertions: 0, Failures: 0, Errors: 0
```

Also added an `is_int()` special case to the constructor, since we often deal with
integer values when constructing a `Money` instance, so we don't need to check for
a more expensive `filter_var()` operation.

…nt equality is also non-matching

This moves away a function call that is otherwise repeated very often, and which can lead to a lot
of runtime overhead for no reason.

Instead, we do this comparison only when the amount is the same (direct equality, faster for the engine).

While calling `Currency#equals(Currency)` may indeed look better from a domain perspective,
`Currency` is `final`, and currency comparison is one of the most frequent operations performed
on `Money` (for internal assertions).

Therefore, removing the method call is both feasible and beneficial for performance:

```
❯ php -dopcache.enable_cli=1 ./vendor/bin/phpbench run --ref=original --retry-threshold=5 --iterations=10
PHPBench @git_tag@ running benchmarks...
with configuration file: /home/ocramius/Documents/moneyphp/money/phpbench.json
with PHP version 8.0.3, xdebug ❌, opcache ✔

\Benchmark\Money\NumberInstantiationBench

    benchConstructorWithZeroIntegerAmount...R3 I7 - [Mo561.632μs vs Mo591.581μs] -5.06% (±3.01%)
    benchConstructorWithPositiveIntegerAmou.R1 I7 - [Mo542.669μs vs Mo550.683μs] -1.46% (±1.00%)
    benchConstructorWithNegativeIntegerAmou.R1 I2 - [Mo579.585μs vs Mo580.812μs] -0.21% (±1.60%)
    benchConstructorWithZeroAndFractionalAm.R3 I8 - [Mo574.055μs vs Mo595.014μs] -3.52% (±1.86%)
    benchConstructorWithFractionalAmount....R1 I9 - [Mo580.926μs vs Mo611.898μs] -5.06% (±2.09%)
    benchConstructorWithNegativeFractionalA.R2 I8 - [Mo587.192μs vs Mo580.123μs] +1.22% (±2.55%)

\Benchmark\Money\MoneyOperationBench

    benchAdd................................R1 I8 - [Mo985.200μs vs Mo987.689μs] -0.25% (±2.61%)
    benchSubtract...........................R1 I8 - [Mo985.114μs vs Mo936.192μs] +5.23% (±2.70%)
    benchMultiply...........................R1 I0 - [Mo988.329μs vs Mo1.057ms] -6.52% (±2.69%)
    benchDivide.............................R1 I7 - [Mo933.611μs vs Mo1.031ms] -9.43% (±0.93%)
    benchRatioOf............................R4 I4 - [Mo392.845μs vs Mo989.503μs] -60.30% (±1.70%)
    benchMod................................R1 I3 - [Mo421.904μs vs Mo401.023μs] +5.21% (±1.72%)
    benchIsSameCurrency.....................R2 I6 - [Mo1.000μs vs Mo2.000μs] -50.00% (±0.00%)
    benchIsZero.............................R1 I7 - [Mo400.636μs vs Mo426.642μs] -6.10% (±1.00%)
    benchAbsolute...........................R10 I9 - [Mo397.953μs vs Mo396.644μs] +0.33% (±2.76%)
    benchNegative...........................R1 I6 - [Mo955.247μs vs Mo983.110μs] -2.83% (±2.45%)
    benchIsPositive.........................R1 I0 - [Mo405.106μs vs Mo392.182μs] +3.30% (±2.71%)
    benchCompare............................R3 I9 - [Mo401.284μs vs Mo397.301μs] +1.00% (±2.12%)
    benchLessThan...........................R1 I9 - [Mo390.481μs vs Mo390.164μs] +0.08% (±1.84%)
    benchLessThanOrEqual....................R1 I5 - [Mo395.329μs vs Mo430.164μs] -8.10% (±2.53%)
    benchEquals.............................R10 I9 - [Mo1.000μs vs Mo3.000μs] -66.67% (±0.00%)
    benchGreaterThan........................R1 I0 - [Mo414.980μs vs Mo390.450μs] +6.28% (±2.71%)
    benchGreaterThanOrEqual.................R1 I1 - [Mo385.041μs vs Mo411.738μs] -6.48% (±2.64%)

\Benchmark\Money\MoneyInstantiationBench

    benchConstructorWithZeroIntegerAmount...R1 I9 - [Mo954.935μs vs Mo898.483μs] +6.28% (±1.18%)
    benchConstructorWithPositiveIntegerAmou.R1 I3 - [Mo913.027μs vs Mo937.671μs] -2.63% (±2.09%)
    benchConstructorWithNegativeIntegerAmou.R1 I0 - [Mo926.714μs vs Mo909.286μs] +1.92% (±2.25%)
    benchConstructorWithZeroStringAmount....R2 I9 - [Mo998.900μs vs Mo933.039μs] +7.06% (±2.79%)
    benchConstructorWithPositiveStringAmoun.R2 I4 - [Mo927.877μs vs Mo857.589μs] +8.20% (±2.17%)
    benchConstructorWithNegativeStringAmoun.R2 I9 - [Mo951.571μs vs Mo904.536μs] +5.20% (±2.64%)

Subjects: 29, Assertions: 0, Failures: 0, Errors: 0
```

…unt()` operation that can be optimized by opcache

```
❯ php -dopcache.enable_cli=1 ./vendor/bin/phpbench run --ref=original --retry-threshold=5 --iterations=100 --filter=Avg
PHPBench @git_tag@ running benchmarks...
with configuration file: /home/ocramius/Documents/moneyphp/money/phpbench.json
with PHP version 8.0.3, xdebug ❌, opcache ✔

\Benchmark\Money\MoneyOperationBench

    benchAvg................................R1 I63 - [Mo399.867μs vs Mo404.221μs] -1.08% (±2.29%)

Subjects: 1, Assertions: 0, Failures: 0, Errors: 0
```

…eading from `bcadd()` and `bcsub()` operations

…er#__construct()` code, adjusted ctor parameter types

…t)` comparison to see if two strings are equivalent

This simplifies checking for the validity of `Number` input values

…` will be given as a parameter

Overall, this means that we can remove some assertions from all multiplications/divisions, therefore slimming down the code even further

…rather than being checked at runtime

…ad of `strpos()` and `substr()`

…634 (comment)

This will allow us to add native type declarations everywhere within the library, to the benefit of
runtime checks, static analysis, as well as OpCache optimizations (where the engine understands them).

Ref: moneyphp#634 (comment)
Ref: moneyphp#634 (comment)

… logic to always work on `string` values

Here we introduce a lot of BC breaks in type signatures, specifically calculators. Values that used to have `float`
as acceptable state are now generally changed to `numeric-string`, although not everywhere (yet).
This is not yet the final form of the codebase, but we need an atomic state where:

 * we are at a newer/better CS level (specifically psalm type declarations and native type declarations)
 * we have a passing PHPUnit/PHPSpec test suite

By changing this, we gain a lot of internal consistency that we can leverage to easier refactor components
that need to do a lot of intensive performance-oriented math operations.

Note that we are also introducing a lot of type contradiction (stricter types, but we still check for input
value shape): that is because we did not yet upgrade `vimeo/psalm`, and therefore we haven't yet tackled
any of these, but rather based our changes on the existing test suite instead.

Here we change the philosophy of the library radically: instead of doing runtime
validation for inputs, we leave those up to the user (yes, really! endorsing a type-checker
will need to be part of this patch), and instead we expect correct values to be passed
in as type-checked upfront.

This way, we get rid of a number of runtime validation tests that are completely avoidable.

PHPCS, PHPStan, Psalm and similar tools are too unstable to lock at minor/major release,
therefore we need a `composer.lock` to keep things frozen during builds.

This will be a massive improvement for contributors, while for maintainers it means that
`composer.lock` will need regular, slow and incremental upgrades over time.

This allows for hunting down mis-uses of the library at type level
also when refactoring/restricting type signatures

…undant code

Since phpspec is no longer first-class citizen of the library, hereby we converted some
of the specs into unit tests, and ensured that all of the API of the library is not
unused (means there's at least another symbol or test relying on it).

In addition to that, operations such as mixed `float/int`, `string/int`, etc math
are now generally removed from allowed code.

…m/phpunit/phpcs from locally installed version

…um mutation score threshold

By using this plugin and enforcing a minimum threshold, we ensure that we are not lowering the quality
of the library by:

 * reducing type-safety
 * reducing code-coverage

…spec scenarios to PHPUnit tests

Calculators are well defined within a fixed algebra, and therefore
do not need to be configured.

Considering that, we:

 * made all `Calculator` implementations `static` and `@psalm-pure`
 * removed all runtime configuration flags from `Calculator`
 * removed `Calculator` discovery: the default `Calculator` is now `BcMathCalculator`
 * added `ext-bcmath` as a mandatory dependency: not a massive dependency for the
   amount of simplicity and improvements gained from this
 * removed `Calculator::supported()`, since it is now up to the user to pick a custom
   `Calculator` implementation, should one be required (if at all)
 * marked the `PhpCalculator` internal, since it is not supposed to ever be used in
   a production environment

… library

…composer-normalize` rules

…phpunit`

… rather than `string|int`

While this reduces overall coverage, it also reduces the amount of noise produced
by accidental coverage during mutation tests, and forces single tests to be much
more precise about what we are testing and covering, leading to more aimed
regression prevention and better SUT quality.

Also, this fixes the CI run, where infection couldn't run due to missing system
locale setup.

…lator` logic

Ref: moneyphp#634 (comment)
Ref: moneyphp#634 (comment)

This check was mostly detrimental to performance, and didn't bring in much.

Ref: moneyphp#634 (comment)

…eed for it anymore

Ref: moneyphp#634 (comment)

…`float` anyware within the codebase

Ref: moneyphp#634 (comment)

…recise

Ref: moneyphp#634 (comment)

Reverts eb32c53
Reverts 91c8091

…stead of a generator

Ref: moneyphp#634 (comment)

…too)