Don't search for pregen'ed AOT invokers, due to failure cost.

When AOT compiling code, or when JITing code that has "def" in it,
we must generate a stub to wrap the target method as either a
DynamicMethod or some type of block callback. These stubs are
normally generated at runtime when the AOT script boots, or when
the JITed method containing a def or block is run.

The logic here originally tried to load existing stubs, for the
rare case where the user has AOT-compiled their application *and*
pregenerated those invokers, such as for environments without code
loading capabilities or to force compiled code into the boot
classloader. However, since 99% of AOT users did not also pregen
the stubs, N method definitions executed in a script meant N
ClassNotFoundException getting raised for the missing stubs, plus
the overhead of proceeding to generate and load the stubs at
runtime.

Because there are likely no users pregenerating the stubs (we
have never publicized the feature and it generates far more
classes than just doing it lazily at runtime), we should prefer
startup time of typical AOT situations. This patch removes the
attempt to load AOT-compiled method stubs before generating them,
instead allowing them to generate and falling back on classloading
if the generated code fails to link.

For a simple experiment -- running -X+C -S rake -T in the JRuby
codebase -- my total execution time went from 5.3s down to 4.9s.
Another user saw improvements as well in normal jitted execution,
which is an unexpected benefit.

Note that this does make the pregenerated-stub feature moot; since
we now always try to generate at runtime, those pregenerated stubs
will almost never be seen. This may impact performance for
applications that pregenerate stubs, but it's unlikely to be
considerably slower since the heaviest lifting is from the
bytecode parsing and linking that always has to happen anyway.