Add BcMath\Number support to NumberField

[NovakHonza]

Summary

PHP 8.4 introduced \BcMath\Number — an object type for arbitrary-precision arithmetic that avoids the floating-point rounding issues inherent to float. Doctrine ORM supports it via Types::NUMBER. This PR adds native support for \BcMath\Number properties in NumberField.

Changes

• Add setStoredAsBcMathNumber() option to NumberField
• Introduce EaNumberType form type (extends NumberType) with StringToBcMathNumberTransformer that handles conversion between form input and \BcMath\Number
• Update NumberConfigurator to convert \BcMath\Number to float for IntlFormatter display
• Throw \LogicException on PHP < 8.4, \InvalidArgumentException when combined with setStoredAsString()
• Add PHPStan ignores for BcMath\Number (not available when analyzing with phpVersion: 80200)
• Fully backward compatible — no changes to existing behavior on PHP 8.2/8.3

Usage

yield NumberField::new('price')->setStoredAsBcMathNumber();

With a Doctrine entity:

#[ORM\Column(type: Types::NUMBER, precision: 8, scale: 2, nullable: true)]
public ?\BcMath\Number $price = null;

Without this option, NumberField sends a float on form submit (causing InvalidTypeException) and passes \BcMath\Number directly to IntlFormatter::formatNumber() which only accepts int|float (causing TypeError).

[NovakHonza]

A small note on the exception type: on line 38 of NumberConfigurator.php, I used \LogicException to stay consistent with how a similar environment requirement (missing Intl extension) is handled in DateTimeConfigurator.php (line 35).

That said, from a PHP semantics perspective, \RuntimeException would arguably be a better fit here — the PHP version check is a runtime environment condition, not a programming logic error. The same code works fine on PHP 8.4+ and only fails on older versions.

If you consider \RuntimeException more appropriate, I'm happy to update it.