call crash if the signal handler is unable to handle the signal

Otherwise, the OS will just keep asking us to handle the signal in an
infinite loop.
always add a trap instruction after a throw

Tail call and dead code optimizations can cause code after a throw to
be eliminated, which confuses findUnwindTarget because it doesn't know
what code is throwing the exception.  So we need at least one
instruction to follow the call to the throw_ thunk.  Previously, we
only added such an instruction when we knew the throw was the last
instruction in the bytecode, but it turns out there are other cases
where it is needed, including certain try/finally situations.
fix StackOverflowError stack walking in tails=true builds

The various Architecture::nextFrame implementations were not walking
the stack correctly when a StackOverflowError was thrown.  The
throwStackOverflow thunk is called before the frame of the most
recently called method has been fully created, and because tails=true
builds use a different calling convention, we need to treat this
situation carefully when building a stack trace or unwinding.
Otherwise, we will skip past all the java frames to the next native
frame, which is what was happening.
Merge pull request #199 from joshuawarner32/master

remove unused constants (fixes #198)
Merge pull request #200 from dicej/stack-signal

fix a few stack walking and signal handling bugs
fix broken Class.getDeclar{ed|ing}Classes implementations

classpath-common.h's getDeclaringClass was trying to look up
non-existing classes, which led to an abort, and I don't even know
what Class.getDeclaredClasses was trying to do, but it was ugly and
wrong.
Merge pull request #201 from dicej/declaring

fix broken Class.getDeclar{ed|ing}Classes implementations