Introduce testing for identifying regressions which can introduce ttrpc deadlocks

As detailed in https://github.com/containerd/ttrpc/issues/72, in the past, `ttrpc` has encountered deadlocks on the server side or client side when mismatching versions were used.

| Version Range | Description | Comments |
|---------------------|-------------------------------------------|------------------------------------------------------------------|
| **v1.0.2 and before** | Original deadlock bug | [#94](https://github.com/containerd/ttrpc/pull/94) for fixing deadlock in `v1.1.0` |
| **v1.1.0 - v1.2.0** | No known deadlock bugs | |
| **v1.2.0 - v1.2.4** | Streaming with a new deadlock bug | [#107](https://github.com/containerd/ttrpc/pull/107) introduced deadlock in `v1.2.0` |
| **After v1.2.4** | No known deadlock bugs | [#168](https://github.com/containerd/ttrpc/pull/168) for fixing deadlock in `v1.2.4` |

While the current version of `ttrpc` does not display any deadlocks, we want to introduce a CI regression test which can test the current code against the following older versions in both server and client scenarios:

- `v1.0.2`
- `v1.1.0`
- `v1.2.0`
- `v1.2.4`
- `latest`

This issue is filed for discussions related to the plan of how such a matrix testing can be introduced for `ttrpc`.