Fix another LockViolation case on Windows

[kcbanner]

#13864 reverted some changes which were causing breakage if the same c file was compiled twice as part of the same compilation. This PR makes the fixes as suggested by this comment there: #13864 (comment)

Changes:

• Add an assert that an exclusive lock is help to writeManifest, to catch this error when it happens.
• Only call writeManifest if an exclusive lock is held.
• Update tests to assert that a cache hit results in holding a shared lock, instead of writing the manifest

Reproduction steps for the LockViolation:

// build.zig
const std = @import("std");
const Builder = std.build.Builder;

pub fn build(b: *Builder) void {
    const target = b.standardTargetOptions(.{});
    const mode = b.standardReleaseOptions();

    const exe = b.addExecutable("template", null);
    exe.addCSourceFile("main.c", &.{});
    exe.linkLibC();
    exe.setTarget(target);
    exe.setBuildMode(mode);
    exe.install();
}

// main.c
#include <stdio.h>

int main(void)
{
    int x = 12;
    x = (x % 2 == 0) ? x / 2 : 3 * x + 1;

    // Uncomment to cause compilation failure
    //x = (x % 2 == 0) ? x = x / 2 : x = 3 * x + 1;
    return 0;
}

1. zig build. This compiles normally.
2. Uncomment the failing line in main.c
3. zig build. This compile fails due to the C compilation error.
4. Re-comment the failing line in main.c
5. zig build. This compiles successfully, but triggers the LockViolation.

Trace:

[matu3ba]

Just curious: Is there a way to stress test this anyhow somewhat reliably?

[andrewrk]

This fix looks just right 👌