LSP can crash when accessing a non existent type from the concurrent slab

[JoshuaBatty]

I noticed we are getting a panic with accessing the concurrent slab in one of the LSP tests here. It's not clear what is causing this but it shows there is a situation where we are trying to access a type from the slab that doesn't exist anymore leading to a panic.

running 60 tests
test code_action_abi ... ok
test code_action_auto_import_alias ... ok
test code_action_auto_import_constant ... ok
test code_action_auto_import_enum ... ok
test code_action_auto_import_function ... ok
test code_action_auto_import_struct ... ok
test code_action_auto_import_trait ... ok
test code_action_function ... ok
test code_action_struct ... ok
test code_action_struct_existing_impl ... ok
test code_action_struct_type_params ... ok
test code_action_trait_fn_request ... ok
test code_lens ... ok
test code_lens_empty ... ok
test compilation_succeeds_when_triggered_from_module ... ok
test completion ... ok
test did_cache_test ... ok
test did_change ... ok
test did_change_stress_test_random_wait ... ok
test did_open ... ok
test document_symbol ... ok
test format ... ok
thread '<unnamed>' panicked at sway-core/src/concurrent_slab.rs:107:14:
invalid slab index for ConcurrentSlab::get
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_display
   3: core::option::expect_failed
   4: sway_core::concurrent_slab::ConcurrentSlab<T>::get
   5: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
   6: sway_lsp::core::session::parse_project
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: test failed, to rerun pass `-p sway-lsp --test lib`