Start using Github Actions for CI tests (#1160)

Start using Github Actions for CI tests (#1160)

This change imports existing Sempaphore CI functionality test harness
and migrates it to Github Actions. Using a stand-alone harness offered
many advantages, but that approach goes against the current custom of
importing CI configurations into being-tested repositories. Semaphore CI
itself switched to such invasive configurations since v2. We have to
start using invasive CI configurations to be able to evolve Squid CI and
solve known CI problems.

While importing the test harness, we made basic CI functionality tests
available from the command line so that developers can run them even
before submitting a PR and while addressing reviewer concerns. They do
require internet access because the tests are downloaded from GitHub,
but they avoid permanent service installations in developer environment.
The tests do create/overwrite logs and start services like Squid. A lot
more work is still required to make these tests user friendly.

The new test configuration/harness consists of two primary parts:

* Github Actions "workflow" configuration, including embedded scripts.
* Various test scripts used by the "workflow" configuration above.

There are many ways to split the test harness among those two parts.
This particular split is based on these split-specific principles/ideas:

1. When running tests locally, developers do not want to risk
   disruptive, permanent, potentially dangerous actions such as globally
   installing new packages or overwriting checked out Squid sources.
   These actions belong to the workflow configuration file that is only
   interpreted by Github Actions, on Github virtual machines. The test
   scripts have only one sudo command (to start a Squid manipulating
   agent as nobody) which is bypassed of the agent is already running.

2. Developers should be able to repeat basic tests from the command
   line, against their version of Squid sources, their Squid builds, and
   without learning the ever-changing testing details. If their PR has
   failed a CI test, they may simple want to run the corresponding
   script locally to reproduce the issue. This means that nearly all
   testing logic belongs to the test scripts, not the Actions
   configuration file (that developers cannot easily interpret/apply).

We also thought that some developers would want to separate
functionality from code quality tests (because those are often applied
at different development stages) and to repeat (many times) just the
failed test case (because that often helps when triaging and fixing
bugs). These considerations resulted in the creation of two scripts,
each accepting individual test case names as optional parameters:

* test-suite/test-functionality.sh
* test-suite/test-sources.sh