Use proto encoding for scheduler workflow next time cache (#5277)

The scheduler workflow keeps a cache of a sequence of calls to
getNextTime to reduce overhead. The cache was serialized as json, this
changes it to serialize as proto. This is made forwards and backwards
compatible by trying to deserialize into both types.

The json decoding of this cache showed up as a significant cost in a cpu
profile of a worker that was doing a lot of schedule workflow replays.
In a simple benchmark of decoding only on my laptop, decoding the proto
was about 20 times faster with no jitter (14 with jitter), and the
encoded proto was 8 times smaller (5 with jitter). Encoding was about 4
times faster (but that's less important).

```
no jitter:
BenchmarkDecodeJson-12            178678             33114 ns/op            1848 B/op         13 allocs/op
BenchmarkDecodeProto-12          2249361              1571 ns/op             288 B/op          3 allocs/op
with jitter:
BenchmarkDecodeJson-12            110619             32657 ns/op            1848 B/op         13 allocs/op
BenchmarkDecodeProto-12          1565641              2336 ns/op             400 B/op          4 allocs/op
```

existing tests (especially replay test for backwards + forwards
compatibility)

The code is a little more complicated and there could be bugs in the
conversion. Note that both json and proto support nanosecond resolution
for timestamps.