Fix bug #1331744, properly handle interface types.

If you have a typed interface (type foo interface{stuff}), but you end
up returning that object via the empty interface (interface{}), it strips
the knowledge about the original interface, and reflect.ValueOf() cannot
create values that point to those types. However, you can play tricks with
reflect.New().Elem().Set() to get a reflect.Value that holds the interface
rather than holding the original object.

The bug was that we were looking up the methods on the original signature,
(which in this case was an interface), and then using the method.Index to
call a function on the concrete type. This worked everywhere so far, because
everything that was returning via an interface only had public methods that
matched that interface exactly, and golang-go sorts methods so they all
lined up.
However, gccgo sorts differently, and private methods can come before the
public ones, and then you notice that the offsets are different.
I added a test that creates 2 implementations that have a different number
of methods, so we know that they will not be in the same positions, and
it properly fails if we don't wrap our obj into the right interface
reflect.Value object.
don't recover the panic just to panic again
Merge pull request #129 from jameinel/api-and-interface-types-1331744

Fix bug #1331744, properly handle interface types.

If you have a typed interface (type foo interface{stuff}), but you end
up returning that object via the empty interface (interface{}), it strips
the knowledge about the original interface, and reflect.ValueOf() cannot
create values that point to those types. However, you can play tricks with
reflect.New().Elem().Set() to get a reflect.Value that holds the interface
rather than holding the original object.

The bug was that we were looking up the methods on the original signature,
(which in this case was an interface), and then using the method.Index to
call a function on the concrete type. This worked everywhere so far, because
everything that was returning via an interface only had public methods that
matched that interface exactly, and golang-go sorts methods so they all
lined up.
However, gccgo sorts differently, and private methods can come before the
public ones, and then you notice that the offsets are different.
I added a test that creates 2 implementations that have a different number
of methods, so we know that they will not be in the same positions, and
it properly fails if we don't wrap our obj into the right interface
reflect.Value object.