update to new module system

[xdBronch]

breaking changes from ziglang/zig#18160
made corresponding prs in known-folders and diffz, iiuc the hashes i used in the zon will still work once the prs are merged, github magic or whatever :p

[xdBronch]

forgot to update the min zig version of course lol

[xdBronch]

also there seems to be a regression relating to build runners being cached so zls cant really use its build runner correctly meaning module imports are broken
ziglang/zig#18438 fixed

[xdBronch]

oh thats funny, the changes to the expectEqual function meant to make them better to work with are actually causing CI to fail

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (5c0bebe) 76.12% compared to head (9fbd994) 76.14%.

Files	Patch %	Lines
src/DocumentStore.zig	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1698      +/-   ##
==========================================
+ Coverage   76.12%   76.14%   +0.01%     
==========================================
  Files          34       34              
  Lines       10007    10007              
==========================================
+ Hits         7618     7620       +2     
+ Misses       2389     2387       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[llogick]

Past experience tells me it might be a good idea to rename the current build runner and use it with zig versions < 2030, some/certain projects only update in large increments.

[Techatrix]

Past experience tells me it might be a good idea to rename the current build runner and use it with zig versions < 2030, some/certain projects only update in large increments.

Any projects that doesn't target the latest Zig shouldn't use the latest ZLS as well.
I would rather have the multi build runner system removed at some point instead of extending it with more versions.
Previous Discussion on this: #1020 (comment)

[llogick]

Past experience tells me it might be a good idea to rename the current build runner and use it with zig versions < 2030, some/certain projects only update in large increments.

Any projects that doesn't target the latest Zig shouldn't use the latest ZLS as well. I would rather have the multi build runner system removed at some point instead of extending it with more versions. Previous Discussion on this: #1020 (comment)

Yeah, well #1396

[xdBronch]

realistically it doesnt matter since the 2 commits are like a day apart but updating the minimum version to the expectEqual change isnt required afaict. i tested earlier and the updated tests work with the new and old expectEqualDeep

[Techatrix]

FYI, I have edited your PR and done the following:

• updated the minimum build version again
• squashed some of your commits
• updated build.zig.zon so that the commit hashes refer to the master/main branch
• updated everything nix related

[Techatrix]

realistically it doesnt matter since the 2 commits are like a day apart but updating the minimum version to the expectEqual change isnt required afaict. i tested earlier and the updated tests work with the new and old expectEqualDeep

The minimum build version had to be updated anyway because of ziglang/#18438, so I did it just in case.

[xdBronch]

ah i actually did something a little sneaky before 😄
i made the minimum version refer to the commit that fixed that issue but the comment refer to the big module pr. in hindsight it probably didnt make much sense to do so but i was being overly pedantic, the comment above says document the latest breaking change that caused a change to the string below: but it was a bug fix not a breaking change :p
either way it doesnt matter because now CI is failing because of yet another breaking change haha

[Techatrix]

Everything looks to be in order finally.
The only thing missing are the nix flakes which I will update in a follow up PR once https://github.com/mitchellh/zig-overlay has updated again.