Fix goroutine leak

[2opremio]

From weaveworks/scope#1767 (comment):

The problem is two-fold:

• there can be two goroutines that attempt to output an item on errIn but the channel only has a capacity of one, so one of the goroutines will get stuck if the closer is invoked (i.e. we hit the <-quit branch), which is why we see one of first two goroutines appear in the goroutine dump. We fix this by increasing the errIn capacity to two.
• the waiter is waiting for input on errs, but invoking the closer ends up terminating the top-level goroutine without outputting on errs, causing the waiter to be stuck. That is the third goroutine we see in the dumps. We fix this by a) removing the returns on <-quit, and b) setting the capacity of errs to one, so that the top-level goroutine doesn't end up blocking if there is no waiter.

[fsouza]

Nice catch, thanks!