Fine grain locking to avoid deadlocks in CU cache

[BoykoAlex]

Only lock necessary pieces.

1. Move project cache notifications outside the locked block
2. Lock minimal pieces of code that use lookup environment

[BoykoAlex]

@martinlippert I was thinking merging this for 4.29.1 as well... but this might have some risk.

Can be reproduced in a workspace with a lot of spring boot projects. Once workspace is opened, invoke content assists and cancel it over and over again. Once in 3, 5 times completion proposals would be stuck at computing.
Deadlock are:

• project added (lock on projects), CU cache invalidating the project (CU cache waiting on lookup env lock) and CU cache parsing a new CU (lock on lookup env) but waiting on the CU cache (shouldn't wait on the CU cache while parsing)
• project added (lock on projects), CU cache invalidating (CU cache lock, waiting on lookup env lock) CU is processed (lookup env locked), i.e. hover and project for CU or any other URL but "projects" are locked

[martinlippert]

If you have a good and reliable test scenario on your machine that keeps working with this change better than before, we can include this in 4.29.1, but beyond that, I would like to take a more careful look into the overall mechanism here. Looks quite complex to me, so looking into this again after 4.29.1 in more depth could make sense - in addition to the fix for 4.29.1.

[BoykoAlex]

I've put this in for 4.29.1 via a081d8a