Add a Debugf helper function to the Concrete environment

[therealbytes]

Rationale

Right now, the environment exposes Debug(msg string) which is simple and easy to integrate with WASM but also cumbersome to use when many values must be printed e.g.,

env.Debug(fmt.Sprintf("Lorem ipsum a=%v b=%v", a, b)

Implementation

Add a Debugf(msg string, ctx ...interface{}) method that generates a string with the format <msg> <name1>=<value1> <name2>=<value2> ... and calls Debug with it. The code above should become:

env.Debugf("Lorem ipsum", "a", a, "b", b)

Feedback wanted regarding the naming of the method and the formatting of the string.

[ODHack 4.0] Contributors: Note that we highly recommend that you comment on the issue by introducing yourself and how you plan on tackling the issue! Just saying you want an issue is not helpful. This will help with assigning tasks, especially if many comment.

[fishonamos]

Will love to hop on this as part of my ODHack Contribution. Adding a Debugf helper function will make debugging less verbose. Instead of manually formatting strings with fmt.Sprintf, we can pass the message directly to Debugf, which will handle the formatting

[wugalde19]

HI @therealbytes , If not assigned to @fishonamos

Can I take care of this one?

[fmmesen]

Hello @therealbytes I'm coming from ODHack. Could you assign this to me, please?

[kamuik16]

I'm interested in contributing to the implementation of the Debugf method. My approach would involve creating a method that allows formatted strings and multiple variables, improving the ease of use when debugging complex scenarios. I suggest naming it Debugf to maintain consistency with familiar logging functions in Go.

Could you provide guidance on where this function would best fit within the existing code structure?

[kamuik16]

@therealbytes