- Need to implement invalidation
- Need to work out a better way to trigger
  the upper-level pass from the lower-level one / put it in the pipeline

For some reason, this is getting bogged down in the _loop analysis_
part of the per-function evaluation...eh? Weird.

The same pass (`FunctionBoundedTermination`) completes as expected when
invoked from a function-level transform pass
(`print<function-bounded-termination>`), but not when invoked from a
module-level transform pass `print<bounded-termination>`

Is this something weird with the proxy?

Several (all?) testdata files were failing when the
`FunctionTerminationPass` was run via proxy (from the module-level
pass), instead of being run at the function level. Unfortunately, "run
from the module" is the only way we think we can handle the call-graph
level analysis.

The symptom was LLVM stalling out -- looping forever? -- when we asked
for `ScalarEvolutionAnalysis`. I opened up LLDB and stepped through,
and... it was fine! Looking at `simple.c`, the pass produced results for
`get_value` and `main` just fine.

...but our functions are not the only functions listed in a module! For
instance, `simple.c` invokes `malloc`; as a result, `malloc` gets a
`declare`d in our module, without a function body. And *that's* where
the analysis was stalling out -- our pass was running on `F.getName() ==
"malloc"`!

Apparently, function-level passes are only run across functions
`define`d in the module -- but the listing of module contents includes
functions `define`d or `declare`d. I haven't really checked this, but it
is consistent with what we've seen, and would explain the difference
between running in function/module modes.

My fix (this commit) is to return `Unknown` if the function does not
have a body, i.e. has no basic blocks. This gets us back to a passing --
though incorrect -- state.

This doesn't propagate it back via the worklist, but it does tell us
about recursive loops.