Allowing PortGroups to bump port revision

[René J.V. Bertin]

>My next thought was that we could add another version field for PortGroup revision.  We could use the highest value set amongst all the port's groups when comparing versions.  That still has the downside of causing problems if a PortGroup is removed. 

Only if the removal causes a revision regression I'd say. 2 ways around that (at least): 
- reindex on revision change, not only revision increase
- also keep track of the number of PGs over which the maximum was determined.

> Unfortunately ports are only re-indexed when their mtime changes,

So, when a `portindex` call does seem to catch a version increase from a PortGroup in certain ports it is probably because the corresponding Portfiles were changed on disk for some other reason, since the last reindexing?

(FWIW, in my case we're talking about the version of a family of KDE ports, so I still need to change the checksums in each member port, taking care of the required mtime change. I just have to be more alert myself not to forget anyone, or remember to use `portindex -f`).

> ... although I don't think we'd be putting this sort of thing in the GitHub
> PortGroup ...

Or the muniversal PG. Until someone does.
And it might be more likely to happen in the libcxx PG, which also seems to be used increasingly often.

Of course this argument begs the question if the portindex command couldn't be made faster, e.g. by porting it to a proper compiled language? No one ever wrote the equivalent of cython or pyrex for Tcl?

R.