Add guidance on goroutine lifecycle management

[abhinav]

This is mostly an RFC based on some internal discussions.
In general, we prefer for goroutines to have well-managed lifecycles.
No uncontrolled background work that cannot be stopped.

This change tries to distill some of the guidance around it into a style
guide entry.
It's not super comprehensive, but it tries to cover some of the guiding
principles.

Rendered: /~https://github.com/uber-go/guide/blob/goroutines/style.md#dont-fire-and-forget-goroutines

[prashantv]

Thanks for adding this, I've been thinking about this same recommendation after leaving multiple reviews in a similar vein!

[mway]

This is great, thanks @abhinav!

[abhinav]

Thanks for the feedback, all. Besides the minor comments, I've made the following changes:

• the original code sample is fully "correct" in that it includes both, how to stop a worker and how to wait for it to exit.
• that you should always wait for the goroutine to exit is now a separate subsection demonstrating use of wait groups and channels for the purpose
• the "don't spawn goroutines in init()" section code sample now includes implementation of how you'd signal stop and wait for exit as well.

[mway]

Good stuff!

[mway]

Are these intentionally ungrouped (e.g. to minimize example LOC)?

[abhinav]

Oops, yeah. Good catch.