Make a separate tree for 10.6 pre-release-specific fixes

[barracuda156]

To begin with, for the context: there are very few ports which require fixes specific to the developer pre-release versions of 10.6 (relevant for PowerPC, but in fact as much applicable to Intel). Perhaps, something around 15–20 altogether, excluding versions of the same (there are several gccs which need identical fix, etc.). Which make up to about ~30 ports.

However:

1. Some of those in present form are not portable – in a sense they will compromise standard 10.6.x, at least potentially. So they should not be in the master in any case.
2. As we know, there are maintainers who happen to oppose fixing their ports for pre-released macOS versions, which makes it impossible to fix those ports, regardless of whether fixes in question are generally desirable, sound etc.

While I oppose the idea to move all PowerPC support to a separate tree or repo, I am perfectly fine, and in fact for, upon reconsideration, having a separate tree for 10a190, where I can place fixes which are genuinely required only for pre-release 10.6 and no other systems.

This would solve, at least partly, a number of problems:

0. We can have Pythons and GCCs fixed for 10a190 straightaway – I have those fixed and working, but Pythons fixes are blocked by their maintainer and GCC fixes in existing form are incompatible with regular 10.6 (and while I can make them compatible even now, I do not yet have a way to make in neatly).
1. For developers and end-users there will be still an official trust-worthy source, even though a secondary one, which is preferable as compared to my personal repo.
2. It will make situation transparent and easy to monitor for everyone who may wish: I do not want to keep being accused of introducing hundreds of 10.6 ppc-specific hacks :) I admit a few hacks are in fact needed, and IMO they should be available to those in need of them, but Ken is right in that such fixes should not compromise any other systems; it is also understandable that in some cases portfiles are too complex already, and any extra code will make them less readable.
3. I can also use such tree for experimental ports specifically targeting PowerPC (not specific to 10.6 ppc), but not being ready for the master. For example, SDL2 and VLC2. This gonna make it easier for others to test such ports (and maybe help with fixing them).
4. If there is a separate tree to which I have commit rights, it make my life easier, after all. I will still have an incentive to make any fixes to that tree sane, concise and complying to Macports policies, since I hope that minimal and safe ones can be accepted into master, at least some of those. But a separate tree will make it easy to review for others, and I do not need to fight over each PR. At the same time it is perfectly safe (since all 10A190-specific stuff is not in the master and does not affect anyone at all) and also, hopefully, addresses Ken’s point of supposed difficulty of getting rid of my fixes (in a case Macports developers collectively decide in favor of that): removing a tree is trivial, if desired.

It is not necessary, at least not from the start, to make any change to the base to pick such a repo in case one is on 10.6 ppc. It can be introduced as an isolated thing: though on Macports Github as a branch, nothing will address it, and if anyone wishes to use it, they will need to tweak their set-up manually.

16. S. Addressing Kirill’s consideration re maintenance difficulty: if the tree is for 10A190 only, this is easy for me to maintain and rebase against the master regularly. I do it anyway for myself. In fact, it is mostly “do it once for a few ports and then just routinely rebase”.

What do you all think?