Twirp

* PR 276 implements interceptors, an elegant way to plugin new functionality to clients and services with a simple but powerful interface.
* PR 277, fixing 257 on the client side, allowing Go clients to talk to services implemented in different languages (e.g. Python) when the proto definition contains Service and Method names that are not CamelCased. Note that only Go services generated with v7 can handle literal routes, previous versions only support CamelCased routes.

Twirp v7 is a major release that includes a protocol spec update. The jump from v5 to v7 is to avoid confusion with the [archived protocol spec v6](https://twitchtv.github.io/twirp/docs/spec_v6.html) that was not released.

Changes in the protocol spec from v5 to v7:

* Twirp routes can have any prefix: `<prefix>/<package>.<Service>/<Method>`. In v5 the prefix was mandatory, always`/twirp`.
* Error code `ResourceExhausted` maps to HTTP code `429`. In v5 it mapped to `403`.

Changes in the Go Twirp v7.0.0 release:

* 264 Optional Twirp Prefix. Implements the proposal 263 with the optional prefix, using an option to specify a different prefix than the default value "/twirp". The default value ensures backwards compatibility when updating the service. Using different prefixes, it is now possible to mount the same Twirp service in multiple routes, which may help migrating existing services from the "/twirp" prefix to a new one.
* 264 also introduces [server options on the server constructor](https://github.com/twitchtv/twirp/pull/264#issuecomment-686170407), that can be used to setup hooks and new options like the path prefix.
* 270 ResourceExhausted error code changed to 429 HTTP status code. This may affect middleware if it depends on a specific status code being used.
* 271 Server JSON responses using EmitDefaults: responses include all fields, even if they have zero-values. This can be reverted to the previous behavior (skip zero-values) with the server option: `twirp.WithServerJSONSkipDefaults(true)`.
* 257 Go services handle literal routes. Fixing part of the issue 244, affecting cross-language communications when the proto definitions are not using the recommended [Protobuf Style Guide](https://developers.google.com/protocol-buffers/docs/style#services).
* 268 Bufgfix: Allow to update context from server Error hooks, so they can communicate with the ResponseSent hook if needed.

Go Upgrade instructions

For the most part, the upgrade to the new version should work out of the box. But there are a few areas to pay attention, depending if your service is using some specific features or not.

Twirp has two components, the `twirp` package and the code generator plugin (`protoc-gen-twirp`). One thing is to upgrade the package to the latest version, and another thing is to re-generate the server/client code with the latest version. You should upgrade the package first, because it works with older generated clients.

Upgrade the `twirp` package to version `v7.0.0` in your project.

* If you are explicitly using `twirp.ServerHTTPStatusFromErrorCode(twirp.ResourceExhausted)`, the returned value will change from `403` to `429`.
* If your service is returning errors with the code `twirp.ResourceExhausted` and you have middleware and/or monitoring tools that depend on the HTTP status code, they will now see a change from `403` to `429`.

Generate code with version v7+ of the plugin `protoc-gen-twirp`.

* If your service is serving JSON requests under heavy traffic requirements, make sure to skip defaults with the option `twirp.WithServerJSONSkipDefaults(true)`. Pass this option as an extra argument to the `New<Service>Server` constructor. See more details on 271

Importing Twirp clients from other services:

* If your service is importing Twirp clients from other services that were generated in older versions, don't worry, they still work.
* The new v7 package works for clients that were generated with the older v5 generator.
* But the new v7 clients require the new v7 package to compile.
* If you have multiple services that depend on each other, update the `twirp` package on all services first. Don't re-generate the code yet. Once all services have the v7 package, you can update the `protoc-gen-twirp` to v7 and re-generate all clients.

This release fixes an issue in the generated Go client code where the request context is not properly passed to the ResponseReceived client hook.

* PR 229 adds the function `twirp.WrapError(twerr Error, err error) twirp.Error`, that returns the same Twirp error but wrapping the original error, that can can be unwrapped later (for example in middleware) using `errors.Is` or `(github.com/pkg/errors).Unwrap`.

* PR 235 adds the ability to use Go 13+ standard library methods `errors.Is` and `errors.As` to unwrap errors from Twirp's internal errors. This works for service errors, usually unwrapped on middleware, and also client errors if they fail on the client, for example a context cancelled error. NOTE: client errors can only be unwrapped if the client was generated with Twirp v5.11.0 or above (even if your service is using a different Twirp version). For older versions, you can still use `(github.com/pkg/errors).Unwrap`.
* PR 227 adds the helper function `AddHTTPResponseHeader`, that can be used to set multiple values to the response header in the same key.

- Fixes the issue in 196, where importing a `.proto` file with the same Go package as the file being generated would not be handled correctly.
- Includes the response body in the error metadata when the response body's error JSON has an invalid Twirp error code to assist with debugging.