Exercise a method containing a `try' statement with several
instructions with a `finally' clause but without any `catch' block,
enclosed in a loop.

When dx processes an integer division (or modulo) enclosing a `try'
block and whose result is assigned to a local value, it is smart
enough not to emit a `div-int' (or `rem-int') instruction when the
divisor is non-null, as it wouldn't be used.  However, dx is not
that clever regarding exception handling: if the divisor is known to
be non-null at compile-time (as is the case in this test), it will
still emit a block with the exception catching and rethrowing
mechanism, even if it is not used.

This used to be a problem for a `try' block followed by a `finally'
clause but with no `catch' block: in that case, the generated Dex code
item would list zero catch block for this method (see
art::CodeItem::tries_size_) and the optimizing compiler would have no
clue that it contains a `try' statement, which it cannot optimize
(yet).  With no hint that this method might contain one (or several)
special block(s) related to `catch'-less `try' statement(s), the
optimizing compiler considered this (these) as dead block(s) and
improperly tried to remove its (their) instructions, sometimes
removing instructions used by others instructions, thus triggering
assertions.  The optimizing compiler was thus adjusted to remove these
instructions in a proper fashion, by removing them as users first, and
then by suppressing them for good.