Clarify forever channel declarations

[SimonAlling]

The current idiom

forever := make(chan bool)

gives the impression that booleans will be sent through forever. But
the channel never has anything sent through it; its purpose is just to
block indefinitely.

This PR clarifies the idiom in two ways:

• bool is replaced by struct{} – the unit type, as Go has no
  bottom type (empty type; ⊥) – clarifying that whatever may be sent
  through the channel will never carry any information.
• The channel itself is replaced by nil – which always blocks when
  read from or written to (see below) – clarifying that nothing at all
  will ever be sent through it, leaving no doubts as to its purpose.

From the specification:

• "A nil channel is never ready for communication."
• "Receiving from a nil channel blocks forever."
• "A send on a nil channel blocks forever."

[SimonAlling]

I'm not experienced enough with Go to know for sure that this is functionally equivalent, so feedback is appreciated.

[SimonAlling]

I have clarified the PR description; GitHub typically doesn't update the resulting squash commit message accordingly, so here it is:

The current idiom

    forever := make(chan bool)

gives the impression that booleans will be sent through `forever`.  But
the channel never has anything sent through it; its purpose is just to
block indefinitely.

This PR clarifies the idiom in two ways:

  * `bool` is replaced by `struct{}` – the unit type, as Go has no
    bottom type (empty type; ⊥) – clarifying that whatever may be sent
    through the channel will never carry any information.
  * The channel itself is replaced by `nil` – which always blocks when
    read from or written to (see below) – clarifying that nothing at all
    will ever be sent through it, leaving no doubts as to its purpose.

From [the specification](https://go.dev/ref/spec):

  * "A `nil` channel is never ready for communication."
  * "Receiving from a `nil` channel blocks forever."
  * "A send on a `nil` channel blocks forever."

[michaelklishin]

Your reasoning makes sense to me. Thank you for contributing!