Consolidated listener notification. Changed multi-failure.

(Brings this project up to date with react
622252dedb2a05c6e3c0ede0192cc9881c7e08e6).

Quoted from the original project:

The change to multi-failure is in three parts:

1. When notifications fail, we now propagate the first failure, rather
than combining multiple failures into a MultiFailureException. Projects
with similar requirements have realized that sometimes throwing an
exception of type A (whatever the listener throws) and sometimes
throwing one of type MultiFailureException results in undue pain for the
caller. The caller will probably fuck up and the MultiFailureException
will get propagated past where they thought it would. Java 7 will allow
us to addSuppressed() the extra exceptions, which is the "right"
solution, but we can't do that until 2025 or so when Java 7 features are
widely enough distributed that we can depend on them. Yay.

2. Notification terminates immediately if an Error is thrown. Error
means shit is fucked. There's no real benefit to trying to soldier on in
the face of an Error, and it needlessly complicates the underlying code.

3. RFuture.sequence() now *always* delivers a MultiFailureException,
even if only one of the sequenced futures fails (rather than delivering
the single exception if only one future failed). This results in a
predictable API which meets the needs of callers: I gave you N
operations that might fail, you give me back an exception that
aggregates the 1 to N failures if there are failures. If I actually care
about the failures, I'll iterate over them, otherwise I'll
just log the whole damned thing and throw my hands up in the air.