[security][CVE-2022-27809] Builtins should always take int64_t, not int

[security][CVE-2022-27809] Builtins should always take int64_t, not int

Builtins are allowed to take 32 or 64-bit integers
(int/int32_t versus int64_t). It's not clear why we allow this, as
integers from Hack are always 64-bit. A builtin taking an int will
just have the upper 32-bits truncated. Depending on the value, this
might change a negative number to a positive one, defeating various
input validity checks.
Remove support for 32-bit integers. Change all of the builtins which
took or returned an int to use int64_t instead. This required a few
fixups here and there, mainly around format strings. If the builtin
uses 32-bits ints internally, I left them. At least the truncation is
now obvious.

Test Plan:
New unit test. Beforehand this large negative input would
be turned into a large positive number, bypassing the "input cannot be
negative" check. Now that it takes int64_t, it is correctly recognized
as a negative number.

---
Initializes m_arr in ArrayInitBase

ArrayInitBase's protected constructor does not initialize
m_arr (presumably because a derived class is meant to do so). However
if a derived class' constructor throws, we'll run the ArrayInitBase
destructor, which will try to release m_arr. If m_arr hasn't been
initialized yet, it can contain garbage and we'll try to release
random memory. The protected constructor should initialize m_arr to
nullptr.

Test Plan:
New unit test which previously failed with ASAN builds

Co-authored-by: Rick Lavoie <rlavoie@fb.com>