Use self-descriptive cache with type tags

[ilevkivskyi]

This should make our cache format more future proof w.r.t lazy deserialization and other features:

• This makes cache ~5% larger (data + meta)
• This makes interpreted performance ~5% worse (just the serialization steps, not overall time)
• No visible performance impact when compiled (probably because all extra indirections like read_str() -> read_str_bare() etc are C calls).

Note that I now serialize various little arbitrary JSON blobs (like plugin data etc) using fixed format, since with the tags we can do this.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[hauntsaninja]

Looks good from a skim.

Should we maybe keep version_id up front and read it first so that we can avoid format change issues?

[ilevkivskyi]

Should we maybe keep version_id up front and read it first so that we can avoid format change issues?

It is a bit more nuanced than that, on one hand we have things like --skip-version-check, so we shouldn't blanket abandon cache if version_id is different, on other hand, we need to abandon cache if version of librt changed (incompatibly) even if mypy version is the same. So my idea is to have two first bytes in cache meta be: librt (low level) cache format version (that would be bumped each time cache layout changes, even if ABI stays the same), and mypy (high level) cache format version, that would be bumped each time we change e.g. type tags, or other high-level cache logic.

I am going to add something like this in a separate PR.

[JukkaL]

Looks good! Glad to see that compiled performance isn't impacted much.