CI: kick off .gitlab-ci.yml for integration with GitLab CI

We start with a matrix similar to that in .travis.yml:

• build + tests, using
  • gcc
  • clang
• various compilation-free immediate maintenance checks

All using Fedora Rawhide, for various reasons:

• spot the possible breakages down the line early (incompatibility in the surrounding software, etc.)
• is reasonably trimmed down (now that glibc-all-langpacks doesn't hog the installation)
• close familiarity on the side of developer(s), at least me :-)

As an extra, experimental measure, we put some hard time limits
on some time-criticial execution, since when they get breached
regularly, we shall reconsider whether just to bump that value
or to change the approach/restructure whole pipeline.
Conversely, when we are blocked on an RPM repo mirror, we
shall rather give up early.

Another notable point is trying hard to cache the floating bits,
so that we, e.g., do not have to run the full round trip to
redownload the packages from an RPM repo mirror all the time.
And yet another, we don't (in an outlook, by uncommenting the
respective part of the config, actually, since we are currently
after the compatibility as back as GitLab 10.8) trigger
full-fledged build + test jobs when there's not reason

• neither of relevant source files got changed, meaning another

optimization for as lightweight testing as possible.

Unlike with .travis.yml, some properties of the CI run are configured
directly in the web interface of the project within GitLab instance
(e.g. CI verdict notifications).

Note that thanks to the staged approach, it might be viable (cf.
build-once-reuse-arbitrarily) to consider replaying some very basic
two node scenarios, for instance; all that's needed:

• addressability of the other peer (introspection via API?)
• ability to run corosync with some very loose parameters (note that plain udpu appears more container-friendly than kronosnet mediation)
• ssh-based inter-communication?
• way to synchronize initially (since even within the same stage, the individual starts may be triggered in a lockstep for waiting on free capacities)

TODO:

• extend the range of tests ("exec" set omitted as it requires more dependencies and perhaps some extra fiddling)
• verify coverage measurement works as expected (test jobs seem to regenerate binaries lazily, perhaps because we trim down the artifacts carried between stages, and hence possibly without proper flags?)
• fix coverage not working with clang
• generate coverage report in a nice format to be stored as an artifact for later perusal
• add automated "git bisect" over the tests fallback for convenience
• possibly extend over other distributions (Debian/Ubuntu ecosystem is satisfactorily saturated with Travis CI, though, IMHO)