The number of candidate bounds during the main `SimpleRangeAnalysis`
recursion was in principle always exponential in the size of the
program, but in practice it did not get out of hand when only `+` and
`-` operations were supported. Now that `*` is also supported, the range
analysis started timing out on the SinaMostafanejad/OpenRDM project. The
problematic expressions in that project are of the form
a*x*x*x + b*x*x + c*x + d
where most of the variables involved are recursive definitions and are
therefore likely to have a large number of candidate bounds.
The fix here is to identify those few binary operations that are most
likely to cause an explosion in the number of bounds and apply widening
to them. Previously, widening was only applied at definitions.
The range analysis wasn't producing useful bounds for `AssignOperation`s
(`+=`, `-=`) unless their RHS involved a variable. This is because a
shortcut was made in the `analyzableDef` predicate, which used to
specify that an analyzable definition was one for which we'd specified
the dependencies. But we can't distinguish between having _no
dependencies_ and having _no specification of the dependencies_.
The fix is to be more explicit about which definitions are analyzable.
To avoid too much repetition I'm still calling out to `analyzableExpr`
in the new code.
