Give Futures clearer start/end and exception semantics

Summary:
Ref T13555. Currently:

• If an exception is raised in "start()", the exception state is not set on the future.
• Futures do not always call "startFuture()" before starting, and do not always call "endFuture()" once they become resolvable.
• If you start an ExecFuture which immediately fails and then call "getPID()" on it, you get an unclear exception.

Simplify these behaviors:

• In FutureIterator, only start futures which have not already started.
• When starting a future on any pathway, run start code.
• When a future becomes resolvable on any pathway, run end code.
• Raise a more clear exception when calling "getPID()" on a future with no subprocess.

Test Plan: Faked a failing subprocess with "$proc = null", ran "bin/phd debug taskmaster" etc. Got clearer errors and more consistent future lifecycle workflows.

Maniphest Tasks: T13555

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