Handling of committed inconsistent/corrupt state

Nomad FSM handling is sometimes strict in handling log entries by insuring that some invariants always hold, and fail early if it notices inconsistencies or invalid state.

While it shows good intention, the state does get into a corrupt state due to random bugs and it makes recovery hard.

We studied a cluster running 0.8 which upgraded to 0.10. The cluster ended up with some corrupt state possibly due to https://github.com/hashicorp/nomad/issues/4299 and summary jobs being out of sync.

These had cascading effects in few places:
* The job summary being out of sync resulted into scheduler not being able to process updates to that job - failures lines included something like the following:
```
2020-05-20T23:33:18.760Z [ERROR] nomad.fsm: ApplyPlan failed: error="error updating job summary: unable to find task group in the job summary: xxx"
2020-05-20T23:33:18.020Z [ERROR] worker: failed to submit plan for evaluation: eval_id=49941cf9-2126-f25b-f718-e6d7ad2db28e error="rpc error: error updating job summary: unable to find task group in the job summary: xxx"
2020-05-20T23:32:34.300Z [ERROR] worker: error invoking scheduler: error="failed to process evaluation: rpc error: error updating job summary: unable to find task group in the job summary: xxx"
```

This was reported as well in https://github.com/hashicorp/nomad/issues/5939 .

* If an job batch deregister eval included a job already, the job de-registration would fail and the entire batch fails to be removed. This happened in this cluster with the following log lines:

```
2020-05-21T15:21:59.197Z [ERROR] nomad.fsm: deregistering job failed: job=""" error="job not found"
2020-05-21T15:21:59.198Z [ERROR] nomad.fsm: DeleteJob failed: error="job not found"
2020-05-21T15:21:59.062Z [ERROR] nomad.fsm: DeleteDeployment failed: error="deployment not found"
```

In both of these cases, strict enforcement of invariants exacerbated the situation and made cluster recovery harder. We can consider having automated processes (e.g. if job summary is invalid recompute it, deletion should idempotent and deleting already deleted job shouldn't result into an error).

In the upgrade scenario above, it's unclear to me how the invalid state came to be. My guess is that it was due to bugs in 0.8 (like the ones linked above) but the upgrade to 0.10 exacerbated the situation.

Should scan the FSM/planner checks and ensure that we can recover once an invalid state is already committed to cluster.