Summary:
This diff adds support for major version upgrades on extensions.

- A preflight check  (`yb_check_installed_extensions`) is added to validate the installed extensions in the cluster. The list of supported extensions: auto_explain, file_fdw, fuzzystrmatch, hstore, passwordcheck, pgcrypto, pg_stat_statements, pg_trgm, postgres_fdw, autoinc, insert_username, moddatetime, refint, sslinfo, tablefunc, uuid-ossp,  hypopg, orafce, pgaudit, pg_hint_plan, hll, pg_cron, pg_partman, plpgsql
     - If any extension outside of this list is installed on the cluster, the check will fail with the message: `Upgrade is not supported for extension <extension_name>. It is installed on database <database_name>. Please uninstall the extension using DROP EXTENSION <extension_name>.`
     - Note: upgrade is **not** supported for pg_stat_monitor.
           - pg_stat_monitor version 2.0 no longer contains the function `pg_stat_monitor_settings`. This breaks upgrade because dump and restore attempts to re-create this function (as it is present in the older version), but fails to load it as it does not exist in the new shared object file. Specifically, `CREATE FUNCTION pg_stat_monitor_settings ...` errors out with `ERROR:  could not find function "pg_stat_monitor_settings" in file "...pg_stat_monitor.so"`.
- Like PG, the extension objects are re-created using the dump and restore. i.e., pg_dump will include the schema definitions for the extension objects, and they will be explicitly added to the extension using `ALTER EXTENSION ... ADD ... `.
- As a final step in pg_upgrade (after the dump and restore), extensions will be upgraded to the default version on YB PG15.
      - In PG, `report_extension_updates()` is used to compare the installed version with the default version and emit `ALTER EXTENSION ... UPDATE` commands into a file as required.
      - In YB, we will simply execute the ALTER EXTENSION commands. Specifically,  `yb_execute_extension_updates()` is adapted from `report_extension_updates()` to execute the commands.
      - We do not have to worry about rollback as the extension upgrade scripts do not alter any DocDB objects.
      - Although the extension upgrade is executed during the binary upgrade, we don't necessarily want to execute all binary upgrade code-paths.
              - Some upgrade scripts (orafce--3.25--4.0.sql) contain `CREATE TYPE` commands. Binary upgrade requires `binary_upgrade_next_heap_pg_class_oid` and `binary_upgrade_next_pg_type_oid` to be set for `CREATE TYPE`. However, during extension upgrade, the `CREATE TYPE` command (or any `CREATE` command in general) is not restoring an object that previously existed, but instead creating a new one. Therefore, no OID preservation is required here.
             - A new GUC (`yb_extension_upgrade`) is added to separate the extension upgrade phase.
      - The .so files for the extensions will either be loaded via `shared_preloaded_libraries` (the tserver flag's value is persisted during the upgrade), or via `load_external_function()` when the extension functions are created.
Jira: DB-13814

Test Plan:
./yb_build.sh release --cxx-test ysql_major_extension_upgrade-test

Manual test for new preflight check that validates installed extensions:

Failed check:

```
yugabyte=# CREATE EXTENSION pg_stat_monitor;
CREATE EXTENSION
```

```
$ ./build/latest/postgres/bin/pg_upgrade --check  -U yugabyte --old-socketdir /tmp/.yb.127.0.0.1:5433 --old-port 5433 --old-datadir ~/yugabyte-data/node-1/disk-1/pg_data_11
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking attributes of the 'yugabyte' user                  ok
Checking for all 3 system databases                         ok
Checking database connection settings                       ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             ok
Checking for invalid "sql_identifier" user columns          ok
Checking installed extensions                               fatal

In database: yugabyte
  pg_stat_monitor

Your installation contains extensions that are not compatible
with YSQL major version upgrade. Please uninstall the extensions
using DROP EXTENSION, and reinstall them after the upgrade. A list of
extensions with the problem is printed above and in the file:
    /Users/fizaaluthra/yugabyte-data/node-1/disk-1/pg_data_11/pg_upgrade_output.d/20250305T155850.551/unsupported_extensions.txt

Failure, exiting
```

Successful check:
```
yugabyte=# DROP EXTENSION pg_stat_monitor;
DROP EXTENSION
```

```
$ ./build/latest/postgres/bin/pg_upgrade --check  -U yugabyte --old-socketdir /tmp/.yb.127.0.0.1:5433 --old-port 5433 --old-datadir ~/yugabyte-data/node-1/disk-1/pg_data_11
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking attributes of the 'yugabyte' user                  ok
Checking for all 3 system databases                         ok
Checking database connection settings                       ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             ok
Checking for invalid "sql_identifier" user columns          ok
Checking installed extensions                               ok

*Clusters are compatible*
```

Reviewers: telgersma, hsunder

Reviewed By: telgersma, hsunder

Subscribers: jason, yql

Differential Revision: https://phorge.dev.yugabyte.com/D42079