Fixed bug #61964 (finfo_open with directory cause invalid free)
Implemented FR #61602 Allow access to name of constant used as default value

This is an improved commit for FR #61602, this fixed the previous
commit 054f3e3's C99 compiler compatibility issue
Implements feature 55218

Allows you to recursively check namespaces under a child node
instead of from the root of the XML doc
Adding in test for feature 55218
Improve check for :memory: pseudo-filename in SQlite
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  Improve check for :memory: pseudo-filename in SQlite

Conflicts:
	ext/sqlite3/sqlite3.c
- Fixed bug #62384 (Attempting to invoke a Closure more than once causes segfaul)
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  - Fixed bug #62384 (Attempting to invoke a Closure more than once causes segfaul)
Remove extra ;
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  Remove extra ;
Remove unneeded and outdated ChangeLog file
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  Remove unneeded and outdated ChangeLog file
- Improved fix for #62384
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  - Improved fix for #62384
- BFN
- BFN
Improve json_encode error handling

json_encode() now returns bool(false) for all possible errors, throws the
respective warning and also sets the respective json_last_error() error
code. Three new error codes have been added:

  * JSON_ERROR_RECURSION
  * JSON_ERROR_INF_OR_NAN
  * JSON_ERROR_UNSUPPORTED_TYPE

To get a partial JSON output instead of bool(false) the option
JSON_PARTIAL_OUTPUT_ON_ERROR can be specified. In this case the invalid
segments will be replaced either by null (for recursion, unsupported type
and invalid JSON) or 0 (for Inf and NaN).

The warning for invalid UTF-8 stays intact and is thrown also with
display_errors = On. If this behavior is undesired this can be remedied
later.
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  Improve json_encode error handling
  - BFN

Conflicts:
	ext/json/json.c
Fix memory allocation checks for base64 encode

base64_encode used safe_emalloc, but one of the arguments was derived from a
multiplication, thus making the allocation unsafe again.

There was a size check in place, but it was off by a factor of two as it
didn't account for the signedness of the integer type.

The unsafe allocation is not exploitable, but still causes funny behavior
when the sized overflows into a negative number.

To fix the issue the *4 factor is moved into the size argument (where it is
known to be safe), so safe_emalloc can carry out the multiplication.

The size check is removed as it doesn't really make sense once safe_emalloc
works correctly. (Would only cause base64_encode to silently return false
instead of throwing an error. Also could cause problems with other uses of
the base64 encoding API, which all don't check for a NULL return value.)

Furthermore the (length + 2) < 0 check is replaced with just length < 0.
Allowing lengths -2 and -1 doesn't make sense semantically and also is not
honored in the following code (negative length would access unallocated
memory.)

Actually the length < 0 check doesn't make sense altogether, but I left it
there just to be safe.
Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  Fix memory allocation checks for base64 encode