Extend ci_build method support for better visible granularity

[jimklimov]

The zproject-inspired way of consolidating the CI rituals into a single script that does various build/test scenarios based on a BUILD_TYPE envvar was added in NUT some time ago as a way to integrate with Travis CI, and was later used with Jenkins and dynamatrix efforts, as well as it is a convenient shortcut on command-line during development.

However, with Jenkins it lacks the visibility of executed stages (and especially pinpointing what failed, as well as dashboard exposure of what was tested). This proposal is to add optional BUILD_TYPE_STAGE envvar support, with stage names defined by implementation in a particular project (if at all) and a way to list such stages a chain of which would implement the BUILD_TYPE with its current choices impacted otherwise by the environment (OS, dep packages available, envvars from CI, etc.) The stages would be defined based empirically on time consumption of that operation and on its fault modes (is configure.ac bad? makefiles for distcheck or docs builds? code that does not build into a binary/lib? unit-tests that fail?)

This would allow the dynamatrix to first query the stages and get a list like "configure", "build", "check", "memcheck", "distcheck" for some scenario (maybe less checks for other BUILD_TYPE scenarios - e.g. those involved with docs builds and not exhaustive codebase testing) and then generate the pipeline sub-stages with that in the name to call ci_build.sh with varying envvars to progress through the scenario. By default, with no BUILD_TYPE_STAGE passed, it would run the same codepath as now and not skip over some activities.

Ideally, this should also support a way to fanout over variants of BUILD_TYPE (which per se currently defines us a scenario such as docs test vs code test), to build the code with different mutually exclusive options (do we want SSL from Mozilla NSS, OpenSSL-0.x, OpenSSL-1.x, OpenSSL-3.x, other, none? Do we build NUT with libusb-0.x or libusb-1.x support? Serial protocols with MGE or SHUT? Is TESTING mode for some codebase enabled or not? etc.). That could be based on ci_build's evaluation of the particular build-agent system (are those different dependencies available to iterate over them?) and would involve separate clean reconfigurations and builds and tests with otherwise same tools and other settings determined by the dynamatrix code based on Jenkins agent labels declaring the capabilities like OS and compiler versions and the chosen C/C++ revision for this scenario.

For SSL support at least, the NUT variant of ci_build already can do the one-or-two builds approach, but since it is part of the monolithic dynamatrix sub-stage to "Test" the project in a particular configuration, we can't tell from the dashboard if e.g. OpenSSL or NSS or both were usable on the build agent platform?

Eventually this feature can be proposed back to the ZeroMQ community and zproject, where they deal with similar variations such as builds with and without code marked as "draft" (meaning committed API "contract" or not yet).

Notably, the part about ci_build.sh reporting which sub-stages it supports, and looping a call over those sub-stages for visibility benefits (and dashboard clutter downsides) is something that would be useful on any CI system, regardless of dynamatrix or Jenkins in general.