Instead pass around `&Zalsa` to callers more to reduce dynamic dispatch, in most of these cases the functions are only called once so the compiler should have enough knowledge to make the extra argument passing virtually free
Change the core operation to be `refresh_memo`.
This is a nice refactoring on its own but it
will also support the refactoring of how
we manage accumulator values.
Under this design, *all* databases are a
`DatabaseImpl<U>`, where the `U` implements
`UserData` (you can use `()` if there is none).
Code would default to `&dyn salsa::Database` but
if you want to give access to the userdata, you
can define a custom database trait
`MyDatabase: salsa::Databse` so long as you
* annotate `MyDatabase` trait definition of
impls of `MyDatabase` with `#[salsa::db]`
* implement `MyDatabase` for `DatabaseImpl<U>`
where `U` is your userdata (this could be a
blanket impl, if you don't know the precise
userdata type).
The `tests/common/mod.rs` shows the pattern.
The traits are now quite simple:
* Database is the external trait
* ZalsaDatabase is the internal one, implemented
by `#[salsa::db]`. It adds two methods,
`zalsa` and `zalsa_mut`. Those give access
to our internal methods.
For now I've hidden the methods behind
`&dyn Zalsa`. This is nice and clean but it may
be worth later refactoring to a `struct Zalsa`.
