Redo the debug interface

[natecraddock]

After merging #52, most of the combined library code is relatively clean. One area I would like to improve is the debug library.

I am not sure on the how or the what, but this is a reminder to take a look and see if we can build a more "ziggy" interface on top of what Lua provides. Bonus points if it also hides some of the differences between Lua versions

[VisenDev]

Relevant
https://zig.news/cancername/applying-the-diagnostics-pattern-in-practice-21ja

[VisenDev]

I would also like an option for lua functions that can cause a lua error to be able to return a lua string somehow.

It would be nice to avoid more of this

    lua.doFile(lua_file_name) catch |err| {
        const lua_err = try l.toString(-1);
        std.log.err("{s}", .{lua_err});
        return err;
    };

maybe just a function like this

pub fn logAndReturn(err: anyerror) anyerror {
   //get the lua error and print it to std err
   //...
   return err;
}

lua.doFile(lua_file_name) catch |err| return lua.logAndReturn(err);

[nurpax]

BTW another comment regarding handling errors. This might be more of a documentation suggestion.

It's now quite possible to wrap a C binding function that returns a Zig error, like so:

    fn print(lua: *Lua) !i32 {
        const self = try lua.toUserdata(sprites.Renderer, 1);
        _ = self; // do something with the userdata
        return 0;
    }
...
    .{ .name = "print", .func = ziglua.wrap(print) },

If the input argument is not a userdata, the first try lua.toUserdata will error out and return error.LuaError, throwing away important Lua error information (like which positional argument was in error).

However, one gets much better error messages if instead you'd do:

    fn print(lua: *Lua) i32 {
        const self = try lua.checkUserdata(sprites.Renderer, 1, "SpriteRendererMeta");
        _ = self; // do something with the userdata
        return 0;
    }
...
    .{ .name = "print", .func = ziglua.wrap(print) },

OTOH, using something luaL_argerror or lua_error might have some surprising gotchas too. For example, would any Zig defers get run if you jump out of a Zig function with longjmp (which happens with Lua error raises).

Some sort of short guide on how to properly deal with errors in bindings might be a great addition to Ziglua docs.