The rationale for why regenerateMembersCache didn't need to hold the Lock()
throughout was subtly wrong. It is true that at least some attempt to
regenerate the cache would see *all* the updates. However, it was possible for
the value of `result` generated by that attempt to lose the race for the final
assignment `channel.membersCache = result`.

The fix is to serialize the attempts to regenerate the cache, without adding
any additional locking on the underlying `Channel` fields via
`Channel.stateMutex`. This ensures that the final read from `Channel.members`
is paired with the final write to `Channel.membersCache`.

Rename getters in conformance with the "Effective Go" styleguide recommendation:
https://golang.org/doc/effective_go.html#Getters

* move constant definitions
* always give the client at least quitTimeout to respond to ping,
  even if registerTimeout or quitTimeout are longer than idleTimeout

It's not really used and I'd rather not have it here unless I'm able to actively maintain it properly and build out the web interface.

I might re-add it later but for now I'd rather not have it unless anyone's actively using it.

also, remove the self-notification check; clients are probably not
monitoring themselves, and it doesn't much matter if they are