Intermediate functions can be called non-incrementally

With an intermediate function like `double`:
```rs
use inc_complete::{intermediate, storage::HashMapStorage, DbHandle, Storage, define_intermediate};

#[derive(Clone, PartialEq, Eq, Hash)]
struct Double(i32);

#[intermediate(id = 1)]
fn double(params: &Double, _db: &DbHandle) -> i32 {
params.0 * 2
}

#[derive(Storage)]
struct MyStorage {
doubles: HashMapStorage,
}
```
If we have access to a `DbHandle`, e.g. via another computation we could call `double` without going through the db first:
```rs
fn foo(db: &DbHandle) -> i32 {
double(&Double(3), db)
}
```
Possible solution: prevent `double` by being accessed by renaming the function to something like `_double_impl` and having `intermediate` automatically generate the `struct Double(i32)` struct instead - but naming it `double` to stand-in for the original function. This also has the benefit of reducing the amount of ceremony required to define a new intermediate computation:

```rs
#[intermediate(id = 1)]
fn double(x: &i32, _db: &DbHandle) -> i32 {
*x * 2
}

// Expands to:
#[allow(non_camel_case_types)]
struct double {
pub x: i32,
}

fn _double_impl(ctx: &double, _db: &DbHandle) -> i32 {
let x = &double.x;
*x * 2
}
```
Difficulties:
- it's unclear what, if any, traits for `double` we should derive by default. The original example uses `#[derive(Clone, PartialEq, Eq, Hash)]` but a user may also likely want `Serialize`, `Deserialize`, or more. There would likely also need to be a syntax for specifying these but now that the struct itself is no longer shown, it is less clear to the user why they may want to do this.
- the `double` struct would still need to be specified when creating the storage type, which may be confusing now that the struct is hidden.