The introduced checks were not correct in two respects:
 * It was checked whether the source encoding of the string matches
   the internal encoding, while the actually relevant encoding is
   the *target* encoding.
 * Even if the correct encoding is used, the checks are still too
   conservative. Just because something is not a "Unicode-encoding"
   does not mean that it does not map any non-ASCII characters.

I've reverted the added checks and instead adjusted mbfl_convert
to first try to use the provided substitution character and if
that fails, perform the fallback to '?' at that point. This means
that any codepoint mapped in the target encoding should now be
correctly supported and anything else should fall back to '?'.

* PHP-5.6:
  fix C89 compat

* PHP-5.6:
  Add more mbfl string size checks (bug #73505)

* PHP-5.5:
  Fixed bug #71704 php_snmp_error() Format String Vulnerability
  Fixed bug #71906: AddressSanitizer: negative-size-param (-1) in mbfl_strcut
  Fixed bug #71906: AddressSanitizer: negative-size-param (-1) in mbfl_strcut
  Fix bug #71798 - Integer Overflow in php_raw_url_encode
  Fix bug #71860: Require valid paths for phar filenames
  Going for 5.5.34

Conflicts:
	configure.in
	ext/phar/phar_object.c
	ext/phar/tests/badparameters.phpt
	ext/phar/tests/create_path_error.phpt
	ext/phar/tests/pharfileinfo_construct.phpt
	ext/snmp/snmp.c
	ext/standard/url.c
	main/php_version.h

* PHP-5.5:
  Fixed bug #71906: AddressSanitizer: negative-size-param (-1) in mbfl_strcut
  Fix bug #71798 - Integer Overflow in php_raw_url_encode
  Fix bug #71860: Require valid paths for phar filenames
  Going for 5.5.34

Conflicts:
	configure.in
	ext/phar/tests/create_path_error.phpt
	main/php_version.h