fix constructor param for FilterIterator

When grabbing the constructor arguments through reflection from the
FilterIterator class, HHVM accurately reports the parameter with name
'it' in accordance to both HHVM's FilterIterator.php and PHP's
filteriterator.inc(1).

PHP however, returns 'iterator'. I suspect this is a core PHP bug but I
am running this through you guys to see if this should be reported
upstream or if I am just imagining things.

For your information, the classes that do derive from FilterIterator
already take an 'iterator' param. In any case, attached is a patch
and testcase to make HHVM compatible with PHP, despite it doing crazy stuff.

1) https://github.com/php/php-src/blob/master/ext/spl/internal/filteriterator.inc#L35
redis should report as a loaded extension

Redis has been implemented in its entirety in PHP by @sgolemon,
and there currently is no way of specifying that it should show
as a loaded extension.

This is a temporary workaround (such as the APC one) to just return true
for extension_loaded('redis') when the Redis class exists. Eventually
this should probably be done from PHP, such as done with
IMPLEMENT_DEFAULT_EXTENSION in C++.
fix stream_get_contents when no offset is specified

File does its own internal buffering and uses m_readpos, m_writepos,
m_position for the purpose of keeping track of file offsets. This means
that current (PHP) position is not in sync with the underlying file
descriptor (m_fd).

This works fine, were it not for the fact that ext_stream calls directly
into pure virtual method readImpl that generally lives in PlainFile
and works directly on the file descriptor that might contain an
invalid (buffered-ahead) position.

This pull request does several things:
- Remove default value 0 for File::read(int64_t length), since that
  implementation returns earlier for 0 values anyway.
- Implement an overloaded method File::read() that reads the remainder
  of the file (until EOF) by using proper File::m_* properties.
- Make ext_stream call into File::read instead of PlainFile::readImpl.
initial version of simplexml refactor
fix crash with stacktrace on a VALGRIND build

I'm not sure why this is needed, or how to properly solve this. But it
solves a crash when the JIT is trying to kick in when HHVM has been
built in with VALGRIND=1 (on a debug build).

@ptarjan said this will make @scannell fix it the right way.