Rollup merge of #157529 - Walnut356:serde, r=jieyouxu,kobzol

Add `tests/debuginfo` data classes to define schema

Part of https://github.com/rust-lang/rust/issues/148483

This is part 1 of 3(?) of upstreaming the new testing infrastructure, after which we can start converting the existing tests and/or replacing old tests with new, better written tests. This patch includes the test data format (in the form of several `@dataclass` classes), as well as serialization/deserialization. `common.py` includes a LOT of comments regarding what information is stored and why we store it. If anything is missing or unclear, please let me know. Some information about GDB that I knew off the top of my head I filled in, the rest will be filled in once GDB support is added.

The next patches will include the `compiletest` plumbing, comparison logic, and error handling.

---

Serialization to JSON is as simple as using the builtin `json.dumps` with `dataclasses.asdict(test_data)`. Deserializing the JSON data is taken care of by `from_dict`, which uses the type annotations (which exist and can be manipulated at runtime 🤢), to detect when a `dict` is actually a dataclass, and then dispatches it to the dataclass's constructor. It's kinda magic, but I hopefully left enough comments that it should make sense. Doing it this way means we never really have to touch this function again, it should Just Work™ even if we adjust the dataclasses themselves.

Converting from LLDB is very straightforward. The only difference between this and my mock-up is how types are handled. Before, I stored full type data for the variable and for the type's field's types (recursively). This lead to a lot of redundant information. Since any given type's data is unique and unchanging for a given target in a given session (as guaranteed by LLDB), we can store exactly 1 instance of each `Type`. Variables and children store their type as a `str`, which can be looked up in `TargetData.types` to test against the appropriate type data. This assumes that type names can't collide, which isn't *entirely* true, but the only instances I've encountered are either LLDB bugs or resulted in LLDB itself crashing anyway, so it should be fine for a highly constrained testing environment like this.

Static fields are currently not handled. As discussed on zulip, we're targeting `x86_64-unknown-linux-gnu` first. The only static fields that Rust outputs are for sum-type enums on msvc targets. Static fields can only be accessed by name (nearly everything else we access we can get an item count and look up by index in a loop). I'm considering my options for how I want to handle those. Realistically, it's not super urgent and can be slotted in at any time (and might serve as a good test later down the road of updating existing test data to a new schema).

r? @jieyouxu, @Kobzol