feat: Add query comment into the query for improved debugging

[wwoytenko]

Closes #998

A common challenge when using ORMs is the difficulty of correlating an executed query in the DBMS with the lines of code that triggered it. To solve this issue, it would be helpful to add a comment in the header of the generated query. In this implementation, if a context with a comment is provided, we’ll include that as a comment in the query.

This feature enhances debugging by including query comments in headers, allowing developers to trace the query's origin. By matching the query comment in the header, it's easier to identify the specific location in the code where the query was executed.

Using this feature uses now can add SQL comment in query header

For example

db.NewUpdate().
   Model(&Model{}).
   Comment("test").
   Set("name = ?", "new-name").
   Where("id = ?", 1)

This will create a query like

/* test */ UPDATE "models" AS "model" SET name = 'new-name' WHERE (id = 1)

This was implemented in go-pg #2011

[wwoytenko]

Looks like it is similar to #1002.

[Aoang]

Here need to filter 0x00

appendComment(nil, string([]byte{'*', 0, 0, 0, 0, 0, '/'}))

[wwoytenko]

Thank you. Added fix + test

[vmihailenco]

Let's move comment string to baseQuery with accompanying method to add/set a comment that is called from Select/InsertQuery.

Also, do we want to support a single comment or multiple comments? E.g. what should be the result of calling q.Comment("comment1").Comment("comment2"). I'd say that it is more natural to allow multiple comments, but if we don't know the answer yet, let's forbid the 2nd Comment call by setting an error on the query.

[wwoytenko]

@vmihailenco I can add multicomment support.
Current implementation add comment with space seapration

/* com */ select 1; 

But I wonder should they be separeated by the new line line

/* com1 */
/* com2 */
select 1;

I suspect there might be a case when we have sharded db and we need to add kind of global instance name in the comment for example when we establishing a connection or via some hook. In this particular case it might be:

/* shard1 */
/* query commment */
select 1;

What do you think?

[Aoang]

It is not advisable to implement support for multiple comments now. When writing SQL using an ORM, the syntax is relatively unordered; however, comments should maintain a specific sequence.
Introducing support for multiple comments now could hinder our ability to implement ordered comments in the future, even if we are currently confident that such an implementation will not take place.

For example:

/* maybe we need to write something */
SELECT /* but seem redundant */ 1;
/* say goodbye to db */