Add lexer to handle query parsing for hints

[michaelpq]

This commit adds a lexer to pg_hint_plan to properly parse the hints from query strings. This implementation is based on PostgreSQL's psqlscan.l, which is largely simplified and made pluggable for the sake of this module as it mostly cares about detecting comments and hints in queries.

This has the advantage of removing all the custom code that pg_hint_plan has invented to parse the query strings, cleaning up some confusing historical behaviors in the module:

• A qual value could be considered as a valid hint, like: SELECT FROM tab WHERE col = '/ IndexScan (tab) */'; This is now parsed as a value, as it should.
• The parsing of the comments was sometimes incorrect, failing to ignore comments that would make hints invalid. For example: SELECT / IndexScan (tab / internal_comment / ) / FROM tab; Any comments internal to the hints are now automatically discarded.

Attempting to use nested comments generates INFO messages each time something fishy is found. Like before this commit, the hints behave the same way.

Note that this makes the GUC pg_hint_plan.hints_anywhere not needed anymore. This will be removed in a follow-up commit.

[michaelpq]

@horiguti This is a follow-up of what I have discussed with you in Ottawa, to add a proper lexer to pg_hint_plan. I'd like to do a second patch that uses yyac to transform the hints into binary trees, but that's left for later.

Adding more people in CC who are likely interested in the topic: @MasahikoSawada, @MasaoFujii, @rjuju .

[michaelpq]

Note: I have rebased this patch on latest HEAD, and refreshed it to include \v in the set of characters to considers as whitespaces.

[michaelpq]

FYI, I am planning to move forward with this patch on master after the release happens so as it is possible to improve the parsing of the query. If there are any objections, please let me know, but we'll have 1 year to digest the change with PostgreSQL 17 in line.