Project loading should happen asynchronously

[mkaput]

Primarily, calling scarb metadata should be an asynchronous process that does not block project model updates like it does currently.

Requirements

• This is a good opportunity to drop the detect_crates_for method and replace it with a proper abstraction. See the description for old issue #6124 for more clues.
• Implement this in such a way, that when doing #6132 we won't have to change a lot here. Primarily, this means that this system should escape async world as early as possible. Use spawn_blocking like we attempt to do in with_db method.
• Avoid calling project refreshing process (scarb metadata, cairo_project.toml parsing) if another instance is already running (but if one is running: always schedule at most 1 extra run to pick any changes that could happen while the previous run was running).
• Gracefully deal with projects which loading fails. In such cases, avoid clearing relevant salsa inputs to preserve as much cached queries as possible. For example, a syntax error in the manifest file (this will make scarb metadata fail) shouldn't cause wiping of all analysis state. Check out what RA does here. DISCLAIMER: this is already done in the old project model, just make sure it works with a new one
• Handle detached files well (i.e. one without matching Scarb.toml/cairo_project.toml well). #6691

[piotmag769]

Gracefully deal with projects which loading fails. In such cases, avoid clearing relevant salsa inputs to preserve as much cached queries as possible. For example, a syntax error in the manifest file (this will make scarb metadata fail) shouldn't cause wiping of all analysis state

@mkaput this is no longer the case, no? We just try to init unmanaged corelib in case metadata fails now

[mkaput]

This is more about recovering from breakage when metadata did succeed already. Take a following scenario as an example:

1. You open OpenZeppelin/cairo-contracts
2. It analyses successfully.
3. You open Scarb.toml and make a syntax error.
4. scarb metadata will now refresh and it will fail

I don't want to lose all the analysis information due to this problem because it is easily recoverable: if we know something about the code already, and this information is reliable, let's persist that information instead of wiping it.

Mind that with detect_crate_for this is already working as intended, but it's a consequence of luck rather than deliberate engineering.