Add PostgreSQL 19 compatibility

[adeshthack]

Description:

PG19 introduces several API changes that break the build. This PR adds

C code changes (pg_stat_monitor.c, hash_query.c, pg_stat_monitor.h):

• Adapt to planner_hook gaining ExplainState *es parameter
• Handle QueryDesc->totaltime rename to QueryDesc->query_instr with
  executor-managed instrumentation lifecycle (query_instr_options)
• Fix LWLockNewTrancheId() now requiring a name argument
• Fix ShmemInitHash() dropping max_size parameter (5->4 args)
• Handle const JumbleState* in post_parse_analyze_hook
• Remove escape_string_warning (dropped from core_yy_extra_type)
• Add missing #include headers guarded by PG_VERSION_NUM >= 190000

Test changes:

• Add regression/expected/level_tracking_3.out for PG19
• Add t/expected/007_settings_pgsm_query_shared_buffer.out.19
• Add PG19 entry to t/018_column_names.pl

All changes use #if PG_VERSION_NUM >= 190000 / #else / #endif guards.
Tested against PG 19devel — all 22 regression tests and 34 TAP tests pass.

Links:
Related PostgreSQL 19 commits:

• postgres/postgres@b9e34283 (planner_hook ExplainState)
• postgres/postgres@5765fbd5 (QueryDesc->query_instr)

Upstream CI only tests PG 14-18:

• https://github.com/percona/pg_stat_monitor/blob/main/.github/workflows/matrix.yml

[lfittl]

To add to this, I'd encourage the extension authors to also look at this commit https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=49cc0d41488b92a1d547e278b459c3b224393c8f;hp=51098839cfb40dc496bb48fe4ea14d19170099ac

That commit made JumbleState const in Postgres 19. As part of testing that commit, I've verified pg_stat_monitor can be adapted by making a change like this: lfittl@054f347

(I also had a separate commit for other PG19 fixes, which is very similar to this PR, FWIW: lfittl@77f6ec1)

[jeltz]

Thanks for the pull request and sorry for the late response, but I think adding PG 19 support is a bit more than this. For example I would want some tests to make sure for example PGQ is supported. And I also wonder if we should not move to the new API for hashes in shared memory.