(based on commit 7866b1e)

(based on commit d15130f)

This special case doesn't seem to serve any purpose that I can discern.
My best guess is that it was necessary at some point, but the compiler
has changed to not need it anymore.

The compiler seems to wrap the returned value in a pointer-type at a
call site as appropriate anyway and defining this method on the value
type doesn't seem correct.

 - Move it into a separate function, similar to
   translateStandaloneFunction().
 - Add some comments explaining quirks of GopherJS's method
   implementation.

(based on commit ccda918)

The main change is that we assign explicit names to all function objects
that correspond to Go functions (named and literals). Function name is
declared as `var f = function nameHere() { ... }` and is visible inside
the function scope only. Doing so serves two purposes:

 - It is an identifier which we can use when saving state of a blocked
   function to know which function to call upon resumption.
 - It shows up in the stack trace, which helps distinguish
   similarly-named functions. For methods, we include the receiver type
   in the identifier to make A.String and B.String easily
   distinguishable.

The main trick is that we synthesize names for the function literals,
which are anonymous as far as go/types is concerned. The upstream Go
compiler does something very similar.

(based on commit 4d24395)

JS function names are subtly different from what vanilla Go may expect,
unless gopherjs#1085 is implemented.
It turns out that a combination of
d5771cc and 22c65b8
subtly changes how node outputs stack trace in a way that breaks my
workarounds in the reflect package.

Instead of further fumbling, I am going to disable the offending tests
temporarily, and I have a proper fix for gopherjs#1085 in the works, which will
allow us to re-enable them along with a few other tests.