When a proxy future wraps a future which throws an exception, resolve with an exception

Summary:
Ref T13528. When you call $future->resolve(), we currently guarantee it is resolved by calling FutureIterator->resolveAll().

resolveAll() does not actually "resolve()" futures: it guarantees that they are ready to "resolve()", but does not actually call "resolve()".

In particular, this means it does not throw exceptions.

This can lead to a case where a Future has "resolve()" called directly (e.g., via a FutureProxy), uses "FutureIterator" to resolve itself, throws an exception inside "FutureIterator", the exception is captured and attached to the Futuer, then the outer future tries to access results. This fails since it's out-of-order.

This can happen in practice with syntax highlighting futures, which may proxy pygments futures.

Instead, "resolveAll()" before testing for exaceptions.

Test Plan:

• Locally, tried to highlight a Paste with an unrecognized lexer extension using Pygments.
• Before patch: fatal when trying to access results of a Future with no results (because it has an exception instead).
• After patch: resolution throws the held exception properly.
• (See also next change.)

Maniphest Tasks: T13528

Differential Revision: https://secure.phabricator.com/D21198