Simpler faults and recovery if penalties are reduced

The spec currently contains some complicated data structures for representing layers of faults and "recovered" sectors. Explanation is lacking, but I think that all exists to represent the case that a sector was unavailable for some period of time fully contained within a single proving period, but available again before it ended. This is predicated on the proof being a long running computation that samples sectors throughout the process.

- Is the proof construction highly likely to have that property? I understand there are still different constructions under consideration, but my takeaway from @nicola’s brief description of "rational post" with no VDF is that it doesn't. "beacon post" would, though.
- Is this complexity really worthwhile? If we avoid heavy penalties for faults (#407) the penalty for losing a sector becomes only the need to re-commit it (#408), any maybe pay up to deal clients
- Does this really solve the problem? In my understanding, it doesn't solve the problem in the case that the sector unavailability crosses the proving period boundary, even if the fault duration is relatively short.

If the penalties of a fault are small and a transient failure can be recovered cheaply (#408), I propose we just allow the PoSt to come with a single list of sector failed sector ids and no "recovered" set. The sectors can be re-committed (possibly even before the proving period ends!). Taken all the way, we might not even need a distinguished done set if the storage power measurement is secure without relying on heavy penalties (#403).

There might be some proof construction internals that are opaque to me that necessitate the layered faults independent of these considerations.

Originally asked [in slack](https://filecoinproject.slack.com/archives/CEGB67XJ8/p1562801887159700) cc @sternhenri @dignifiedquire @whyrusleeping

Start by reading the fault, recovery, and proving-period discussion in this issue, then review linked issues #403, #407, and #408 and the referenced Slack context. Determine whether the proposed single failed-sector list is compatible with the proof constructions under consideration and boundary-crossing failures; done requires an agreed design and corresponding specification updates.

Written by the indexing model from the issue text.