Revert "Fix for bad_shell_exec failing depending on the user's shell"

Summary: This reverts commit 62eb6be5d23126089f8c2619da976d7f23550a71.

Reviewed By: @ptarjan

Differential Revision: D1423366
set PHP_VERSION to 5.6

Summary: Now that @elgenie landed splats and variadics, we are feature complete with 5.6.
Closes #3003

Reviewed By: joelm, smith, eletuchy, liranuna

Differential Revision: D1426390

Conflicts:
	hphp/NEWS
Use size_t for string length parameters which are checked against MaxSize

Summary: A common pattern is to reserve space with the ReserveString mode of the
String constructor and then to put data directly into the string buffer
with memcpy() etc. The reserve length was an int, which led to
truncation and exploitable integer overflow for many callers. Added four
test cases demonstrating exploitable heap overflows due to the use of
ReserveString.

There is generally very little performance benefit to using a smaller
type in an argument, since 64-bit alignment is used when passing
parameters on the stack, and 64-bit registers are reserved when passing
in registers. This is in contrast to object storage where there is a
clear rationale for the use of 32-bit types.

So:
* Use size_t for length in all variants of StringData::Make().
* In the version of StringData::Make() which takes a null-terminated
  string with implicit length, do not truncate the return value of
  strlen().
* Use size_t for length in reserve(), shrink() and escalate(), since
  these call the modified StringData::Make() and so can benefit from
  64-bit size checking.
* StringData::setSize() is the one exception; it still uses int, on the
  basis that it is non-throwing, and making it throw would probably mean
  making it  non-inline. In the four test cases, StringData::setSize()
  is called with a smaller size than the one used for the preceding
  StringData::Make(), so it is safe in those cases.

Also:
* Fix a bug in allocFlatForLen() where the length could overflow before
  it was checked against MaxSize. If len is approx. UINT_MAX-2, then
  uint32_t(sizeof(StringData)+len+1) would be a small integer less than
  StringData::MaxSize.
* Fix integer truncation in f_utf8_encode(). If the input string is
  slightly larger than 1GB, data.size()*4 would be a small positive
  integer. Casting to size_t allows the error to be trapped by
  StringData::Make().

Reviewed By: @edwinsmith

Differential Revision: D1431966