[red-knot] Remove <Db: SemanticDb> contraints in favor of dynamic dispatch

[MichaReiser]

Summary

We used to have a mixture of functions/methods that accept &dyn Db + HasJar and methods that were generic over Db.

The problem with this approach is that calling a method that accepted a Db: HasJar wasn't possible when only holding a reference to a &dyn Db or it required repeating the HasJar constraint.

This PR aligns our traits with Salsa by:

• Introducing a new DbWithJar<Jar> trait. The trait itself is empty, but it requires the type to implement HasJar<Jar> and Database
• Make DbWithJar a base trait for all the Db traits (SourceDb, SemanticDb, LintDb etc)
• Change all methods to take db: &dyn SemanticDb as the argument. This simplifies the function signatures a lot

The last change isn't strictly related and maybe I should have done it as a separate PR. However, it removes the
query and mutation methods from the database traits because we can just call the functions directly. This aligns our API with salsa20202.

I've mixed feelings about it. It is nice, because it reduces repetition. However, it does reduce discoverability because you can no longer write
db. to discover all queries/mutations.

Test Plan

cargo build

[MichaReiser]

Creating a Db is now a bit more work but I don't mind that. We should have at most one Db per crate.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[carljm]

Looks good!