ext/Intl: Fix IntlDateFormatter offset type validation

[LamentXU123]

Now in IntlDateFormatter::parseToCalendar we verify if the offset is a int

 <?php
  $fmt = new IntlDateFormatter('en_GB');
  $fmt->setPattern('VV');

  $offset = 'offset';

  try {
      $fmt->parseToCalendar('America/Los_Angeles', $offset);
  } catch (TypeError $e) {
      echo $e->getMessage(), PHP_EOL;
  }

IntlDateFormatter::parseToCalendar(): Argument #2 ($offset) must be of type int, string given

reproduce here
However, in IntlDateFormatter::parse() and IntlDateFormatter::localtime() we silently accept offset that is not a int and turns it into 0

<?php
  $fmt = new IntlDateFormatter('en_GB');
  $fmt->setPattern('VV');

  $offset = 'offset';
  $fmt->parse('America/Los_Angeles', $offset);
  $fmt->localtime('America/Los_Angeles', $offset);

This will not throws an error, reproduce here

At least for consistence's sake, we should reject non-int offset in these functions (This also aligns with previous fixes about avoiding silently casting).

[Girgias]

Ah the reason they are were using z is because they are by-ref params... ignore my prior review. Or it might just make sense to introduce a custom Fast ZPP specifier for the extension.

[LamentXU123]

Or it might just make sense to introduce a custom Fast ZPP specifier for the extension.

Ha. Let's see in the future if I can have time to figure out how the params specifier works in Zend entirely. I still only have a vague idea about how they works that can support me to write new stuffs but I am not confident about refactoring.