fix dialog backend on MacOS

[nmacholl]

Overview
This revision fixes an issue where the Unix dialog backend is compiled for MacOS builds causing OS dialog windows to fail.

Here is an example error:
File dialog driver unsupported (supported values for SDL_HINT_FILE_DIALOG_DRIVER are 'zenity' and 'portal')

Resolution
This revision delivers two changes. First, SDL_cocoadialog.m is added to the cocoa source group and a new unix_dialog group is added containing the Unix dialog backends. Second, the unix_dialog group is added to the C source files in src/linux.zig to make the Linux build whole.

Verification
Verified with a small example program, which fails with the above error prior to this fix, but opens dialogs correctly after.

const std = @import("std");
const sdl = @import("sdl3");

var done: bool = false;

fn dialogCallback(
    userdata: ?*anyopaque,
    filelist: [*c]const [*c]const u8,
    filter: c_int,
) callconv(.c) void {
    _ = userdata;
    _ = filter;
    if (filelist == null) {
        std.debug.print("dialog failed: {s}\n", .{sdl.SDL_GetError()});
    } else if (filelist[0] == null) {
        std.debug.print("dialog canceled\n", .{});
    } else {
        std.debug.print("selected: {s}\n", .{filelist[0]});
    }
    done = true;
}

pub fn main() void {
    if (!sdl.SDL_Init(sdl.SDL_INIT_VIDEO)) {
        std.debug.panic("{s}", .{sdl.SDL_GetError()});
    }
    defer sdl.SDL_Quit();

    const window = sdl.SDL_CreateWindow("dialog example", 640, 480, 0) orelse {
        std.debug.panic("{s}", .{sdl.SDL_GetError()});
    };
    defer sdl.SDL_DestroyWindow(window);

    sdl.SDL_ShowOpenFileDialog(dialogCallback, null, window, null, 0, null, false);

    while (!done) {
        var event: sdl.SDL_Event = undefined;
        while (sdl.SDL_PollEvent(&event)) {
            if (event.type == sdl.SDL_EVENT_QUIT) return;
        }
        sdl.SDL_Delay(16);
    }
}

[MasonRemaley]

Thanks for the PR! I was tempted to suggest that we just move these files to .linux, but I guess these do work on other Unix systems. It looks like the way you've structured it matches the upstream CMakeLists.txt which is probably a good idea.