Resumability, caching, partial processing and interactivity

1. When a pass fails, it would be nice to be able to exclude it and continue. It requires retdec to store some state on disk, such as the plan of passes and auxilary info from each pass.
1.a Currently even to redo a call to the decompiler to get both python-like and c-like pseudocodes after the lifting has been done one has to either restart the process from scratch. It is slow.
2. retdec often detects functions signatures and types wrong. For example some funcs with variable count of arguments are decompiled wrong, and the code near them looos meaningless too. It would be nice to have a way to fix such signatures and then to allow retdec propagate the changes. And this should be fast.

An idea of a way to implement it.

1. A daemon hosting the decompiler algorithms
2. It also creates an LSP proxy, that is plugged into a LSP server for C, like clangd. Refactoring commands are passed to the original server, but also mutate the internal state of `retdec`.
3. The decompilation results are not a single file, but a dir of files connected to each othe. When a file is modified manually, the daemon should detect what has changed, update its internal model, and reemit the code given the updated model.

The issue names no files, tests, or entry points to start from. It proposes broad daemon, persistent-state, LSP, and interactive decompilation work, but does not define a bounded first milestone or a concrete completion criterion.

Written by the indexing model from the issue text.