Consolidated listener notification. Changed multi-failure.

I resisted consolidating the notification code because the type shenanigans
needed to wire it all up resulted in code that was annoyingly ugly. However, I
decided to punt on all that and just have a single suppress warnings where the
notifier class calls the underlying listeners. It's reasonably unobtrusive and
the notification code remains simple and readable.

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.