* use `inventory` for static ingredient registration
* remove unnecessary synchronization from memo tables
* use global ingredient caches for database-independent ingredients
* add manual ingredient registration API
* remove static ingredient index optimization when manual registration is in use
* fix atomic imports
* simplify ingredient caches
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.
