When KDevelop starts up, we will quite early receive the background
parse requests for the last opened documents in the session. These
then often get added to the background parser (BP) before the project
controller is fully initialized - i.e. before any project was even
tried to be loaded. This means the m_loadingProjects safety guard in
the BP does not kick in and we create parse jobs with "broken"
environments, i.e. missing include paths and defines for kdev-clang.
If, and only if, the document has been modified since the last time
KDevelop was started, we would actually parse the document with the
broken environment, leading to flickering when we show the result
for the broken environment before reparsing it after the project gets
opened with the correct environment. Additionally, this of course
adds useless load to the startup phase and frees up resources better
spent elsewhere at this point.

Note that since the project controller itself delays its
initialization via the eventloop, we have to add a new signal to
ensure we resume the background parser only once we have tried to
open all previous projects, such that the m_loadingProjects safety
guard in the BP can kick in properly.

This is not fully integration-tested, as it's pretty complicated
to do so. Rather, we only test the individual parts automatically.
The full integration test was done manually via:

• create kdev session and open some project
• open a file in that project
• close session with file still opened
• touch file on disk to force reload on next startup
• restart kdevelop session
• check visually and via CLI output whether file gets reparsed twice, i.e. before the project was loaded and afterwards

This patch series ensures it only gets reparsed once after the project
finished importing.