Remove initialisation lock

[tomv564]

This PR proposes to replace the initialisation lock with necessary checks and state management.
As far as I know there is no requirement for servers to respond to initialise in a certain time, so we should stop punishing our users for using servers like Metals.

Will not attempt to fix other edge cases related to server initialization as they can be solved in future work.

Bugs to fix

• Go to Definition by LSP seems not to utilize LSP properly for the new tab #845

  • Make sure sessions with same but different case paths match files being opened
  • Stop opening files outside workspace if workspace folders are defined
  • Make sure to not open more files for sessions that are initializing

• 0.9.3 reintroduced issue #79 #860

  • REVERTING Disable a server only for a specific folder of the project, if it fails to init
    • We don't need complexity to support working with broken setups/servers
  • Do prefer longest workspace path
    • TODO: I didn't check what VSCode does with nested folders but we may want to match their behaviour.

Issues reintroduced

• Working with files outside the current workspace folder #844
  • Maybe want to support files outside of workspace path but it has often caused issues.

Besides locking logic, this was also reverted

• Session state #853 (keeping sessions out of dict if not ready, seems helpful but not needed to fix any issues?)
• Turn initialize timeout number into a setting #875 (initialize timeout setting)

To do

• restore any valuable tests reverted

[tomv564]

Reviewed the old tests and decided to add a specific one for the open-in-second-folder-while-first-folder-starting-session case.

[tomv564]

Thanks for the review, you pointed out some stuff that is worth fixing and I'll take a moment to prepare for handling the flow server issue as well