Parse messages from guru on close_cb, not exit_cb

[guns]

There is a race condition in async_guru in which not all messages from
a guru call are displayed:

1. An async guru call is started.

2. Lines streamed from guru are appended to a message list in
   callback().

3. The guru process ends, exit_cb() is called, and the list of
   messages is processed for display.

4. The rest of the lines from guru are appended to the message list.

Note that callback may still be called after exit_cb, as noted in
:help exit_cb:

"exit_cb": handler	…
			Note that data can be buffered,
			callbacks may still be called after
			the process ends.

This race was recently exposed by Vim v8.0.1073, which avoids a
redraw after statusline evaluation changes a highlight. Since vim-go
modifies the goStatusLineColor highlight definition on async calls, the
corresponding redraw acted as a delay, masking this data race.

The solution to this problem is to process guru output in close_cb,
which is called after all callback calls are complete.

[guns]

The other async routines likely need to be fixed in the same manner, but I didn't look into it.

[fatih]

Thanks @guns 👍

[bhcleek]

Is this likely to be the source of problems whereby Vim seems to not be repainting the screen?

I often find myself having to ctrl-l or even ctrl-c (which based on output in the statusline, is clearly is actually cancelling something) in order to make Vim usable again. Sometimes there just seems to be a small delay and sometimes Vim is mostly unresponsive until ctrl-l or ctrl-c. I mostly see this behavior in Normal mode. In some cases, the keys I'm pressing (e.g. j, k, etc.) are written to the screen (but disappear after ctrl-l) until a later time when they seem to be processed by Vim...