pg_upgrade fails when extension_control_path is used

Hello

The upgrade process from 18 to 19devel using `extension_control_path`
fails due to some extensions having the `$libdir/` string hard coded in
the `module_pathname`.

The finding was done by Niccolo Fei while working on the images
extension in CloudNativePG, this feature relies on the
`extension_control_path` GUC that was included in PostgreSQL 18 to
allow having extension in small images. This is done by having a
directory layer with two main paths, one for the extension `.sql` and
`.control` files, and another for the `.so` files or any file that
requires to be added into the `dynamic_library_path`. These two things
trigger the bug during the upgrade.

The problem may look simple and like it can be reproduced with any lib
that is added to the `dynamic_library_path`, but the problem is due to
`pg_upgrade`. Using the `probin` field from `pg_catalog.pg_proc` as the
string used to pass to the `LOAD` instruction when loading the
extension again during the upgrade process gives the following error:

could not load library "$libdir/test_ext": ERROR: could not access
file "$libdir/test_ext": No such file or directory

This problem was already difficult to explain so I decided to create a
test for this, and the error above is the result of the test without
the patch to the `function.c` file.

The patch uses pretty much the same technique that was used in the
`extenion_control_path` patch, that it removes the `$libdir/` string
when the name of the extension is required.

The implementation of the test is something that I would like to get
help on, I moved the location a couple of times to arrive to this one
because it didn't fit in any other place. Also, it makes it easier to
implement the `make` support for it, but I'm still having doubts if
it's the right place.

I'm attaching the patch with the fix and also with the test for it.

Thanks everyone for the reviews!

--
Jonathan Gonzalez V. <jonathan(dot)abdiel(at)gmail(dot)com>
EnterpriseDB