Disable optimistic optimizations if there are too many rollbacks.

This is a protection mechanism against the potential exponential
blow-up of tryOrRollback, in the general case. If, during the
optimization of a given method, more than 256 rollbacks occur,
then we bail out completely, cancel everything, and start the
optimization of the method from scratch, but this time disabling
any optimistic optimizations.
Inlineable classes optimization.

Given some constructor call such as
  new SomeClass(params)
where SomeClass is an inlineable class, the optimizer will
optimistically try to inline the class as a record, which
basically means that its fields become local variables.

If the reference to the instance escapes the method in any
way (typically because it is returned, or passed as a
receiver or an argument of a non-inlined method), then the
optimization is rollbacked.

There are several typical cases of inlineable classes in
code produced by Scala:
* IntRefs and co, which externalize local vars captured by
  lambdas. If the lambda is inlined, they can be inlined
  back as well.
* Tuples used as multi-value ifs or matches.
* Anonymous function classes not optimized as closures by the
  compiler, but still inlineable at link time.
* ArrayOps classes.

The optimization is also useful for small datastructures used
a lot in local computations. This is typical of mathematical
constructs, e.g., 3D vectors.