Support for bind_front

[kunitoki]

This pull request introduces support for partial function application in LuaBridge via a new luabridge::bind_front utility, making it easier to register partially applied functions with automatic type deduction. The documentation and test suite have been updated accordingly, and several enhancements have been made to function trait detection and callable support.

Enhancements to Partial Application and Function Registration:

• Added luabridge::bind_front, a drop-in replacement for std::bind_front that allows partial application of function arguments with automatic deduction of remaining parameter types, enabling easier and more concise registration of bound functions in LuaBridge.
• Updated the documentation (Manual.md) to describe and provide examples for luabridge::bind_front, including its advantages over std::bind_front and usage with member functions. [1] [2]

Improvements to Callable and Function Trait Detection:

• Enhanced function trait and callable detection logic in FuncTraits.h to better support functors, lambdas, and objects with custom call operators, improving robustness and flexibility when registering different callable types. [1] [2] [3]

Testing and Build System Updates:

• Added new tests in NamespaceTests.cpp to verify correct behavior of both std::bind_front and luabridge::bind_front with various function signatures, ensuring correctness and coverage of the new feature. [1] [2]
• Updated the build system (justfile) to include convenient targets for opening the project, building, and running tests.

[skrat]

Perfect. This looks very useful for passing around state or context. Does this also work with luabridge::newFunction? I find myself using luabridge::newTable and creating my API there, as this can be dynamically turned on (luabridge::setGlobal) and off (same, but with nil). And in that context, luabridge::newFunction is used instead of Namespace and addFunction. I would rather use Namespace with its chaining API, but I can't "turn it off" when I need to.

[kunitoki]

Does this also work with luabridge::newFunction?

yes it does, everywhere we expect a callable.

What do you mean by but I can't "turn it off" when I need ?

[skrat]

So in my use case, I keep lua_State* around for longer period. In my Lua scripts, there's informal interface, such that C++ calls, eg. draw and fetch function in the same Lua script. And while calling it, draw has access to some Draw API that I create via luabridge::newTable + luabridge::newFunction + luabridge::setGlobal, but you can't use that from fetch, and vice-versa. So after I call draw (from C++) I disable the draw API by luabridge::setGlobal (nil).

That's one way to do it. I could keep the global of draw API, and ignore the calls, by doing checks in C++, but that would be incredibly verbose.

Another way would be if I could store Namespace as a first class object, and register / unregister it on a particular lua_State* at will.

[kunitoki]

You can take advantage of the namespaces but still register them as tables, see this:

lua_newtable (L);

luabridge::getNamespaceFromStack (L)
  .addFunction ("test", +[] (int x) { return x; })
  .addFunction ("bar", &bar);

lua_setglobal (L, "draw");