[RFC] Exposed parsed value of php.ini numeric directives

Hello all,

While working on some issues in WordPress relating to displaying the configured
max upload and POST sizes I came to realize that PHP doesn't appear to expose
any way of knowing the value of a php.ini directive if that value is
interpreted as a numeric/long value (parsed via OnUpdateLong and
OnUpdateLongGEZero, see main/main.c). It will return the string value which
was configured and (such as 14m) but not the internal value parsed from it
(such as 14680064).

While I started porting zend_atol into WordPress to better interpret values
such as 14MB (14680064) or 0x5teak_and_egg (5368709120) or 03136k
(1669120) I realized that it's not fully possible to do this, specifically when
the configured value would overflow when computing the byte-size suffix, such
as for 9223372036854775807g, which I believe will have a different result on
different platforms.

Noticing a few issues surrounding post_max_size and friends, I suggest
introducing a new function which takes as its input a numeric string as would
be given in ini_set( 'post_max_size', ... ) and returns the value that PHP
internally parses if it were set with that.

Applications could then read the configured value with certainty and wouldn't
have to duplicate and maintain the internal C code from php-src as user-space
PHP.

$post_max_size = ini_get( 'post_max_size' );
$post_max_size_bytes = ini_numeric_value( $post_max_size );

Posting here as my first message, thanks for your patience with my
unfamiliarity of the process and format. Would like to know your thoughts on
the new function and any ideas for a proper name as I don't particularly feel
like I have found a good one yet.

Recap of why this exists:
 - Applications cannot currently know the configured value of post_max_size
 - If an application wants to approximate that value it needs to replicate
   internal C code from php-src but this will breakdown in
extreme-but-allowed cases.
 - Knowing the configured values is important for communicating relevant and
   related configuration settings to users and for internal logic. e.g. Show a
user how large of a file they can upload before uploading it and prevent them
in JavaScript from doing that.
 - Of several approaches considered this was the simplest way I could find to
   add functionality without implying much bigger changes. Complexity inherent
to working with these values is left in application code, but by exposing the
parsed "byte size," those applications can accommodate without having different
interpretations of the actual configured values.

Proposed in https://github.com/php/php-src/pull/8454

Related PR in WordPress, replicating the zend_atol() logic in user-space
https://github.com/WordPress/wordpress-develop/pull/2660

Thanks for the feedback!
Dennis Snell
dennis.snell@automattic.com