Try harder to return DEADLINE_EXCEEDED when we should

Do this by ensuring that the alarm callback has had a chance to run on a
call before returning status to the application.

If we do not do this:
- the server alarm could be scheduled and run
- it will write a RST_STREAM with a status that loses the deadline
  exceededness (because that is unexpressable in HTTP2 error codes)
- it will be received by the client and processed
- the client will return an INTERNAL error (the lossy re-encoding of the
  server status), and then run its alarm handler to set the status to
  something else