Streamline handling of Futures and PIDs in daemons

Summary:
Ref T13555. Currently, the daemon future may resolve into a failure state immediately inside "start()", and not have a valid PID when we read it.

Instead, read PIDs from the current active future in all cases, using "hasPID()" to test for the presence of a valid PID.

Since we don't query the PID immediately, we no longer need to explicitly start the future.

Also fix an issue where the same future could be added to the overseer pool more than once if it threw on "resolve()". In general:

• Before we "resolve()" a future, detach it from the DaemonHandle: we're always done with it.
• Catch exceptions on resolution and treat them the same way as subprocess resolution errors. These aren't common, but are possible in the general case.
• Have DaemonHandle add futures to the future pool directly when they're created.

Test Plan:

• Ran daemons with intentional subprocess creation failures, saw clean recovery.
• Ran daemons with intentional resolution exceptions, saw clean recovery.

Maniphest Tasks: T13555

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