提出引入“编译时数据注入”机制，将镜像源数据与业务代码分离，降低维护门槛

Hi, RubyMetric, I recently started using chsrc heavily, and it's really convenient to switch sources. It saves a lot of time. However, I noticed that some mirror sites seem to have gone down, so I thought I might as well update them. Then I looked at the code in the recipe and found that although the official documentation says "even those who are not familiar with C can write it," in practice, to change a URL, you still have to search through the .c file for half a day, and you have to be careful not to mess up the logic. For people who have never touched C, there is definitely a psychological threshold. So I had an idea: couldn't we separate the list of mirror sources (i.e. the URLs) for each target from the C code and put them in a separate JSON (or YAML/TOML) file? Then, if someone finds that a source is no longer available, they can just change the URL in the JSON file and submit a PR, without even having to install the compiler. After that, I looked through the project's design documentation again and saw that you said "the main program does not provide configuration files, it is clean and free of contamination," which is a great idea. So I came up with a compromise solution: maintain a pure data file (such as data/ruby.json) in the repository, which only contains the names and URLs of the mirror sources. Then, during compilation, we can automatically convert these JSON files into C code (such as generating a static string array) using a Makefile or a simple script, and compile them together with the business logic into the final binary. In this way, the user still gets the same clean single file, without any external dependencies, but the threshold for maintaining the source list is reduced to zero - just change the JSON file. I think this solution is great, as it retains the original design intent and makes community contributions much simpler. I'm familiar with C myself, and I often tinker with build scripts. If you think this direction is feasible, I can help set up the whole thing, including: designing the data structure for JSON, writing a conversion script (using shell + jq or even writing a codegen in C), modifying the Makefile/CMake to integrate it into the build process, and migrating the existing recipe data to JSON. Of course, if you have a better idea or think that this change is too big and not worth it, that's fine. I'll just consider it as a brainstorming session. After all, the tool itself is already very useful, and this is just a nice addition. I'd like to hear your thoughts. If the direction is OK, I can open a draft PR to see how it works.