port:gdbm +compat naggles (affecting the Python ports)

[RJVB (René Bertin)]

I just found out 2 nuisances with port:gdbm's +compat variant:

1) the build process will pick up and link to the installed $prefix/lib/libgdbm.X.dylib ... which will of course disappear when you activate the new gdbm version. The +compat variant thus needs to be bootstrapped by first installing the -compat version, OR the user needs to be instructed to move $prefix/lib/libgdbm_compat.dylib aside during the configure+build steps.

2) if you build any port:pythonXY version it will detect and link to libgdbm_compat.X.dylib, e.g.

> otool -L /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload/_dbm.cpython-311-darwin.so
/opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload/_dbm.cpython-311-darwin.so:
        /opt/local/lib/libgdbm_compat.4.dylib (compatibility version 5.0.0, current version 5.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

It seems that the Python ports need to declare some kind of build conflict with port:gdbm+compat unless they want to start declaring a dependency on port:gdbm (*which they don't ATM*).

(Actually I ran into 1) on Linux, but there is no a priori reason why the same thing wouldn't happen on Mac.)