Introduce CallOptions, to support future per-call options (like timeouts)

[jhump]

This doesn't add anything new (like per-call timeouts) yet, but it sets up the APIs to allow adding it in the future.

The main change is to replace the use of Headers as an argument for every RPC invocation to instead be a new CallOptions type, and request headers are one of the options. (In this PR, they are actually the only option. But we'd add per-call timeouts in the future, and possibly even per-call options relating to compression.)

This is done in a backwards-compatible way so that updating to this version of the library does not require re-generating code or changing application code. So it keeps the old method signatures, but deprecates them. In the generated code, the deprecated functions all have default implementations in the interface to call the new form, so that the generated implementation classes only need to override the new signature.

You can get an idea for what the generated interfaces look like by looking at the changes in ProtocolClientInterface.

You can review this commit-by-commit. I ran full tests (including the whole conformance suite) after each commit, as a way to verify backwards-compatibility of gen code and application code. The first commit updates the library; the second commit updates the gen-code; the third commit updates application code.

[jhump]

I'm going to hold off on this change. I think this is definitely useful -- both to support per-call timeouts as a feature in the future, but also as a pattern that lets us extend the API further in the future without breaking callers. But it's not really necessary just to fix the timeout issues, which is really my current aim.