fix windows build
Merge branch 'PHP-5.4' into PHP-5.5

* PHP-5.4:
  fix windows build
Fix test - on CI somebody could create a process in the meantime
Merge branch 'PHP-5.4' into PHP-5.5

* PHP-5.4:
  Fix test - on CI somebody could create a process in the meantime
5.5.12RC1 setup
5.4.29 is next
Merge branch 'PHP-5.4' into PHP-5.5

* PHP-5.4:
  5.4.29 is next

Conflicts:
	configure.in
	main/php_version.h
Fixed bug #67079 Missing MIME types for XML/XSL files
Fixed bug #67081 DOMDocumentType->internalSubset returns entire DOCTYPE tag, not only the subset
Merge branch 'PHP-5.4' into PHP-5.5

* PHP-5.4:
  Fixed bug #67081 DOMDocumentType->internalSubset returns entire DOCTYPE tag, not only the subset
updated NEWS
correct the bug #67081 fix
Merge branch 'PHP-5.4' into PHP-5.5

* PHP-5.4:
  correct the bug #67081 fix
updated UPGRADING
Fixed bug #67072 Echoing unserialized "SplFileObject" crash

The actual issue lays in the unserializer code which doesn't honor
the unserialize callback. By contrast, the serialize callback is
respected. This leads to the situation that even if a class has
disabled the serialization explicitly, user could still construct
a vulnerable string which would result bad things when trying
to unserialize.

This conserns also the classes implementing Serializable as well
as some core classes disabling serialize/unserialize callbacks
explicitly (PDO, SimpleXML, SplFileInfo and co). As of now, the
flow is first to call the unserialize callback (if available),
then call __wakeup. If the unserialize callback returns with no
success, no object is instantiated. This makes the scheme used
by internal classes effective, to disable unserialize just assign
zend_class_unserialize_deny as callback.
Merge branch 'PHP-5.4' into PHP-5.5

* PHP-5.4:
  Fixed bug #67072 Echoing unserialized "SplFileObject" crash

Conflicts:
	ext/standard/var_unserializer.c
updated NEWS
These links to ~helly don't work anymore.
Merge branch 'PHP-5.4' into PHP-5.5
Fixed test case for 5328d42