- Revised 'protoc' section and 'Documentation' section as LisaFC suggested.
- Added 'Examples' section as LisaFC suggested.

Resolves: #5661

Obvious in hindsight, if the cas failed, we still created the subchannel
call object and then left it dangling.

Fixes a leak observed on master in the past 48 hours.

It was possible for entries in watchers[] to be deleted by another thread before we called begin_poll.

I'd like to do something nicer than this eventually... but that'll be easier once we've got the polling loop cleaned up (which is currently WIP)

Revert "Pass a non-infinite deadline to grpc_completion_queue_next() to prevent queues from blocking indefinitely in poll()"

There is a comment above IsCancelled that says when it is ok to use this.

- Have the server clear the accept_stream callback prior to destroying
  the channel (required a small transport op protocol change)
- Have the transport not enact transport ops until parsing is completed
  (prevents accept_stream from disappearing mid-parse)

We suffered a bug whereby doing a follow-up write to another write could
resurrect a deleted stream, causing all sorts of crash.

Fix: when a stream becomes writable (vs when we start writing) take a
ref on the stream, and only relinquish it once we're done writing.

Pass a non-infinite deadline to grpc_completion_queue_next() to prevent queues from blocking indefinitely in poll().