#66389 XMLRPC decoding 64bit integers

**This is not yet ready to merge.**

As stated in bug [#66389](https://bugs.php.net/bug.php?id=66389), php's included xmlrpc extension fails to properly decode 64bit integers even when compiled on a 64bit system.

This pull request:
* Fixes decoding 64bit integers
* Encodes 64bit integers into an \<int\> tag.
  * This breaks [bug40576_64bit.phpt](https://github.com/php/php-src/blob/master/ext/xmlrpc/tests/bug40576_64bit.phpt) because it tests for a failure to encode a 64bit integer properly.
  * This breaks the XML-RPC spec which says \<int\> & \<i4\> should only contain 32 bit integers. 64bit integers should be encoded with an \<i8\> tag.


There are 4 possible resolutions before this can be merged. I have ordered them in based on my approval of each solution.

#### Break the spec and put 64bit integers into \<int\>
**Advantages:** PHP can encode 64bit integers.
**Disadvantages:** Any parser that strictly adheres to the spec may fail to handle \<int\> exceeding it's specified limits.


#### Output \<i8\> in place of \<int\> in all encoding
**Advantages:** PHP can encode 64bit integers.
**Disadvantages:** The output of this extension will change, and parsers that do not support  \<int\>, \<i4\> & \<i8\> properly may break (although such parsers would have been relying on a bug in the first place).

#### Add an opt-in to enable proper 64bit integer handling
**Advantages:** PHP can encode 64bit integers.
**Disadvantages:** Requires people who expect this sensible behavior to know that they need to enable it manually. Many will observe the current buggy behavior and never realize there is a way to opt into the expected behavior.

#### Output \<int\> for all 32bit integers, and \<i8\> for all 64bit integers.
**Advantages:** Everyone who relies on the current behavior is using 32bit integers only, so no existing functionality will be broken.
**Disadvantages:** Complicates the xmlrpc extension code in exchange for being aware of how big an integer is and adjusting how it is represented accordingly. Based on my observations this doesn't fit in will with the design of the extension.

#### xmlrpc_encode should convert everything to a 32bit integer
**Advantages:** Output will remain exactly the same
**Disadvantages:** This introduces a permanent limitation in exchange for backwards compatibility, and will cause `$x != xmlrpc_decode(xmlrpc_encode($x))` when handling large integers.

-----------

I look forward to input on how this should be addressed.