Custom server endpoint that returns the list of top-level steps

[FrancoisAucoin]

Quick summary

Commit message: Implemented a custom server endpoint that returns the list of top-level steps defined in the specified workspace's root build.zig file.

Note: I made my changes relative to the 0.16.0 release tag, so I will need to rebase against the latest branch and fix the conflicts. But I still wanted to get some feedback to see whether the maintainers would consider this feature a contribution.

Detailed summary

Let me start by being transparent about why I worked on this feature: I thought that it would be cool to implement a task provider in the vscode-zig extension (here's my fork).

That being said, I browsed the ZLS codebase and realized that pretty much everything was already in place for this to work, as this project's custom build runner is doing the heavy lifting and storing the required information inside a structure called BuildConfig.

So here is how the feature works at a high level:

• The LSP client sends a request to customZig/listBuildSteps with the following params object: { workspaceUri: string };
• The server, in its private processMessage method's .other prong, handles the new method;
• The new handler tries to retrieve the appropriate DocumentStore.BuildFile instance from the server's document_store property; and
• The found BuildFile instance's tryLockConfig method gets called and, upon success, returns a reference to a BuildConfig object, from which the top-level steps (names and descriptions) are extracted and returned from the handler, which the server then sends as a response to the client.

But to make this work decently, I had to make a few extra modifications:

• I added a public method to DocumentStore named primeBuildFile, which internally calls the private getOrLoadBuildFile method for its side effects, because my understanding is that the build.zig files are analyzed lazily. Without this, no information would become available to the client until either the root build.zig file was opened in the editor, or a user action like code navigation was attempted. While the first call to the endpoint will likely return nothing, the client implementation would still, in theory, be able to prime the server with a dummy request upon connection. I know this isn't ideal, but that's how I solved the problem for now (but I am obviously open to suggestions).
• I modified the BuildConfig.top_level_steps property from a []const []const u8 type to a []const BuildConfig.TopLevelStepInfo type, where TopLevelStepInfo is a simple structure with two fields: name and description (the goal was to hold the step's description in addition to its name). This schema modification meant that a bunch of .json files used for the build runner's test cases also needed to be modified.
• Finally, I added a brief subsection in the README.md to describe the new endpoint and how to use it.

How to test the feature (in VS Code)

As mentioned above, I have forked the official vscode-zig repository and implemented a task provider that directly uses this new ZLS endpoint.

To test out the feature:

1. Clone that extension branch.
2. Run npm install inside the project root.
3. Open the project in VS Code and launch a debugging session.

IMPORTANT: The new feature in my fork of the vscode-zig extension is gated behind enablement flags that intentionally default to false. I chose this default because I didn't want the server's build runner to automatically spin up in the background without user consent. A user who wants this feature can easily enable it, but that should be their explicit choice.

Additionally, you must configure the extension to point directly to the ZLS binary built from this branch. Your VS Code settings.json should look like this:

{
    "zig.zls.path": "/Users/your-username/path/to/your/zls-clone-at-the-pr-branch/zig-out/bin/zls",
    "zig.zls.enableBuildStepTaskProvider": true,
    "zig.zls.enableEagerAnalysis": true
}

Here is what the task picker looks like for a basic Zig project in VS Code:

If the current PR eventually ends up being approved, I will also submit a PR for my vscode-zig fork.

Thank you for your time!

Thank you for taking some of your precious time to look at this PR. I very much appreciate it! :)