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 el problema con el escenario de dmypy testBlockerBadBuild y compáralo después con el escenario equivalente de actualización directa de mypy mostrado en el informe. Sigue cómo afecta el error de sintaxis bloqueante a las ejecuciones posteriores de recheck o de actualización; se considera terminado cuando la ejecución final no analiza la a.py excluida anteriormente y ambas reproducciones pasan.