GitHub post-extract shenanigans

[Aaron Madlon-Kay]

Hello all.

The github 1.0 portgroup does some post-extract shenanigans to
normalize the result of extracting the distfile: e.g. a GitHub project
`me/myproject` will, as retrieved from GitHub, extract to
`me-myproject-0123abc`; this is moved to `myproject` via globbing:
https://github.com/macports/macports-ports/blob/46c352bcc820ef80909e27a57d2f5eb71569abc6/_resources/port1.0/group/github-1.0.tcl#L81

### My question

I am wondering why the above is done rather than doing the following,
which extracts directly to the desired `worksrcpath`:

extract.mkdir yes
extract.post_args-append --strip-components=1

Example extract invocation (simplified):

cd "/path/to/worksrcdir" && /usr/bin/gzip -dc
'/path/to/distfile.tar.gz' | /usr/bin/tar -xf - --strip-components=1

This seems to nicely solve the problem without relying on the format
of the tarball root. Is there a reason we are not using this solution?

### Background

The following confluence of issues led me to the above solution:

1. The golang portgroup has specific requirements for the worksrcdir
related to the GOPATH (long story)
2. The github portgroup post-extract manipulations require that the
worksrcdir be already present, or that the result of extraction
matches the expected format
3. When `github.tarball_from` is `release` the result of extraction is
unpredictable, so it needs to be handled by the port
4. The github portgroup's post-extract block can't be overridden or
pre-empted, so additional post-extract blocks can't resolve this
conflict

The `extract.mkdir yes` solution ensures that the worksrcdir is
correct regardless.

An alternate solution might involve a flag to enable or disable the
github portgroup's post-extract manipulations, or a new variable to
specify the expected result of extraction independently of worksrcdir.
But these seem inelegant if the `extract.mkdir yes` solution is
viable.

Thanks,
Aaron