Intermediate functions can be called non-incrementally

[jfecher]

With an intermediate function like double:

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<MyStorage>) -> i32 {
    params.0 * 2
}

#[derive(Storage)]
struct MyStorage {
    doubles: HashMapStorage<Double>,
}

If we have access to a DbHandle<MyStorage>, e.g. via another computation we could call double without going through the db first:

fn foo(db: &DbHandle<MyStorage>) -> 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:

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

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

fn _double_impl(ctx: &double, _db: &DbHandle<MyStorage>) -> 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.