Following the discussion in#94, I decided to add more columns to pg_wait_sampling_current/history/profile

I've added most of the columns from request in#94, but some fields from "pg_stat_activity" (=localBackendStatusTable) like query_text, query_start, query_id (if we actually took it from "pg_stat_activity") work in the following way: they save values at the start of the query and DO NOT clear those fields when the query has ended. So after executing "select 1;" in some client backend we will always sample its query_text and query_start until we execute other query. We specifically avoided this kind of sampling when we were making our way of tracking query_id with Executor hooks.

All new columns are added to new views with suffix "_extended". Those views COULD be changed between extension versions, while existing views without those suffixes SHOULD NOT be changed.

One more thing to highlight - since we have to look intolocalBackendStatusTable when we sample some columns, we have reduced perfomance. This is unavoidable and is noted in updated README. BUT, in PostgreSQL 13-16 we can't reliably linkProcGlobal andlocalBackendStatusTable arrays and from this was bornget_beentry_by_procpid. For each interesting process fromProcGlobal we have to iterate throughlocalBackendStatusTable. This has O(n^2) time complexity, where n is a number of all backends. Very inefficient. I probably could remake the collector code to iterate throughlocalBackendStatusTable first and then find corresponding entries inProcGlobal but I have not investigated it and am not sure it would be faster (it may be faster, depending onProcGlobal access/iteration)

There could some sloppy code, including possible "you should copy the struct here, not use pointer" moments

Everyone is welcome to review the code and share their thoughts.