python ports: update to use openssl 3, allowing dependent binaries to be redistributed

[mascguy (Christopher Nielsen)]

Utilizing OpenSSL 3 should help eliminate the current license conflicts, which prevent redistribution of binaries for dependent ports.

NOTE: This ticket covers our foundational Python ports only - python{26,27}, and python{32..39,310}. Assuming that can be done (?), without having to immediately do so for all Python libs/components, dependent upon those.

[cjones051073 (Chris Jones)]

For some(*) ports using the openssl PG, switching to openssl 3 is just a matter of adding

openssl.branch 3

to the portfile in question.

(*) I say some because if that works depends on how amenable the build in question is to using an openssl installation that is from a different install area (libexec) to the primary prefix (e.g. /opt/local). 'regular' builds, e.g. ./configure, cmake etc. usually have configuration options to set this (and the PG already tries to handle cmake internally). python builds are a bit different and I am not sure how this would work with them.

My gut feeling is doing this en-mass with the above (say by putting it into the python PG) will not work as enough ports won't like it, to make it a non-starter. For them, access via the shim openssl port, which currently points to 1.1 still, might be the way to go. So to do this we might well end up back at the discussion as to when would be the right time to make openssl 3 the default (which can now be done by just changing the default branch in the openssl PG).

[kencu (Ken)]

just change the python Portfiles to build with openssl3 ...nowhere else.

the license fix will trickle down to 5000 ports, none of which care how python is built, but are whacked by the python <-> openssl license anyway.