Daemon can lose updates if there is a blocking error in intermediate run

Inline options parsing causes files to force-included in the build if they were previously excluded. For example this test fails with "Unrecognized option..." on the last run:

[case testBlockerBadBuild]
$ dmypy start -- --follow-imports=skip
Daemon started
$ dmypy check a.py
a.py:1: error: Unsupported operand types for + ("int" and "str")
== Return code: 1
$ {python} -c "import shutil; shutil.copy('a.py.2', 'a.py')"
$ dmypy recheck --update b.py --remove a.py
b.py:1: error: invalid syntax
== Return code: 1
$ dmypy recheck --update c.py --remove b.py

[file a.py]
42 + 'no'

[file a.py.2]
# mypy: why-is-this-file-checked-again
42 + 'no'

[file b.py]
syntax error

[file c.py]
# OK

In fact, a.py shouldn't be even parsed on the last run. Note that it is actually correctly not parsed if the error on the second run is non-blocking (like 42 + 'no').

Note that exactly the same problem appears if update is called directly, this test equally fails with same symptoms:

[case testBlockerBadBuild]
# flags: --follow-imports=skip
# cmd: mypy a.py
# cmd2: mypy b.py
# cmd3: mypy c.py

[file a.py]
# OK

[file b.py.2]
syntax error here

[file c.py.3]
# OK

[file a.py.3]
# mypy: this-file-is-not-in-build-in-cmd3-why-is-it-checked

[out]
==
b.py:1: error: invalid syntax
==

Reproduce the issue with the dmypy testBlockerBadBuild scenario, then compare it with the equivalent direct mypy update scenario shown in the report. Trace how the blocking syntax error affects later recheck or update runs; done means the final run does not parse the previously excluded a.py and both reproductions pass.