Allow parsing into Zoir.Node.Index (it's easier to parse build.zig.zon at runtime now)

[MasonRemaley]

Some schemas can't be represented by Zig types.

For example, as #22775 points out, build.zig.zon's schema can't be represented by a Zig type since it uses field names as map keys:

.{
    .name = "foo",
    .dependencies = .{
        .these = .{
           // ...
        },
        .fields = .{
          // ...
        },
        .could_be_named_anything = .{
            // ...
        },
    },
    .paths = .{""},
}

This will be addressed for importing zon at comptime by #22907.

It's possible to handle this case at runtime by dropping down to std.zig.Zoir, but this is cumbersome--especially if most of your type conforms to a Zig type, but a few fields don't.

This PR makes it possible to, for example, parse the build.zig.zon above at runtime using the following schema:

struct {
    name: []const u8,
    dependencies: Zoir.Node.Index, // <-- this wasn't a thing before
    paths: []const u8,
}

Name and paths will be parsed as expected. dependencies will get the index of the Zoir node, allowing you to handle that field as you like--possibly even calling back into std.zon.fromZoirNode at some point on pieces of it if you want!

This allows you to mix and match the higher and lower level parsing APIs at will, making it much easier to parse build.zig.zon and other schemas that don't map directly to Zig types at runtime.

Other Changes

• Status renamed to diagnostics. This better matches its usage now that you may want to read the parsed Zoir from it.
• The AST and Zoir fields on diagnostics are no longer nullable, instead they just default to empty. This saves space, but more importantly, it makes the API simpler.