feature: expose database contents as inherent method on Ingredients

[davidbarsky]

This PR redesigns the functionality introduced in #640 so that the dump-all-database contents methods are on the Salsa struct ingredient instead of the database's Storage. I think this is an improvement for two reasons:

1. This design is closer to the original DebugQueryTable trait.
2. At least within rust-analyzer, it's not feasible to get access to the underlying storage from methods that only have a &dyn SomeDatabase. However, it is feasible to access the ingredient

Example

Here's an example for interned structs (input and tracked structs have an identical API):

#[salsa::interned]
struct InternedStruct<'db> {
    name: String,
}

let _ = InternedStruct::new(&db, "Hello, world!".to_string());

let interned = InternedStruct::ingredient(&db)
    .entries(&db)
    .collect::<Vec<_>>();

Note that the entries method is defined on the {interned, input, tracked}::IngredientImpl. The more optimal API would be to define entries on the Salsa struct itself, alongside ingredient. However, this is substantially more annoying to feature-flag through macros.

Notes

While I don't have a good idea how to access a tracked function's memos, I also don't really know how much it makes sense to do so outside of some migrations.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	7b0744e
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67a528e6b72dd6000895ebee

[codspeed-hq]

CodSpeed Performance Report

Merging #676 will not alter performance

_{Comparing davidbarsky:davidbarsky/per-ingredient-debug-entries (7b0744e) with master (9cfa5a8)}

Summary

✅ 9 untouched benchmarks

[MichaReiser]

Exposing the methods on the ingredient does make sense to me.

While I don't have a good idea how to access a tracked function's memos, I also don't really know how much it makes sense to do so outside of some migrations.

Not saying we have to do this as part of this PR but having the same functionality for queries seems useful because most queries (e.g. the source text or parsed AST) in Ruff aren't tracked structs or inputs but getting a count of alive values would be a useful debug statistics.

[davidbarsky]

Exposing the methods on the ingredient does make sense to me.

How would you feel about moving entries to the Salsa struct itself once we stop exposing the underlying storage mechanism?

While I don't have a good idea how to access a tracked function's memos, I also don't really know how much it makes sense to do so outside of some migrations.

Not saying we have to do this as part of this PR but having the same functionality for queries seems useful because most queries (e.g. the source text or parsed AST) in Ruff aren't tracked structs or inputs but getting a count of alive values would be a useful debug statistics.

Ah, I naively assumed that most queries in Ruff were Salsa structs. In that case, we should add this functionality to tracked functions, but I'd rather do that in a followup: tracked functions feel substantially more difficult than Salsa structs, but that might also be my unfamiliarity.