out-of-memory checkpointing

goal: results should not (never? in weak small cache?) be stored in an
in-memory memo table. so that memo table should be not present in this
implementation. instead all memo questions go to the sqlite3 database.

this drives some blurring between in-memory caching and disk-based
checkpointing: the previous disk based checkpointed model relied on
repopulating the in-memory memo table cache...

i hit some thread problems when using one sqlite3 connection across threads
and the docs are unclear about what I can/cannot do, so i made this open
the sqlite3 database on every access. that's probably got quite a performance
hit, but its probably enough for basically validating the idea.

this hangs right now because update_memo is moved to a different place and
it now has different semantics (compared to when I initially implemented this
patch): the Future is now not-populated, so we can't ask the future for the
result. which means we need to inject the result in a different way.

the three usecases: sqlite3, in-memory and traditional on-disk checkpoint,
maybe needs some thoughts about the completion semantics and data structures
to go with it.

Author: benclifford