Just like the already existing read methods, which work globally on the
text, there are multiple ways of reading from a single segment. It is
possible to read a single character, a string denoted by an index and an
offset and a string denoted by a start index and an end index.
In addition, there is also a way to get the entire string, which will be
useful for copying segments inbetween a specified range.

The mapping methods, check if an index or range points into the current
segment. If not, they adjust the index or range, so that it is valid for
the next segment, that means subtracting the length of the current
segment. Thus they are mapping an index global to the text into an index
local to a segment. Additionaly some will update a length.
The reading and writing methods differ in that the writing ones will map
an index or range pointing directly after the current segment into it,
so that it will be appended to the the current segment.

Inserting a string is parted into two methods which must be called
together. Failing to do so is UB. This is done, because the allocation
part can fail, but doesn't do anything, and the actual insertion needs
the allocation to have token place, but can't fail. That why it will be
possible, to preserve the semantics of a failure, which is without
effects, on a higher level later.

Functions, that work in terms of a TextSegment only work on a single
one, instead of on the whole list of segments. While the next pointer is
still contained in the segment, which would otherwise infer an
unnecessary indirection, allocation and waste space, the user of the
segment is now responsible of maintaining it. Thus a segment isn't
opaque, but it was never intended to be, as it only makes sense in the
context of a whole text. This choice simplifies implementing a
TextSegment and even justifies its existence, as otherwise it would just
shift the complexity from the Text to the TextSegment, instead of
parting it. This is still violated by the three copy methods, which need
to be rewritten later, as the manipulation takes place on copying.

These were excluded to separate files, because Mark was thought to make
use of them.

Originally, the version has been started with 0.9 in the hope to shortly
reach 1.0. Sadly, this might take a while. What is deemed neccessary, is
a module mechanism, a way to include static fragments, maybe from a file
or from a database, maybe a parser for HTML and handling of CSS, at
least as serving static CSS. Also the API/ABI must be considered stable
and include mechanisms for addition, and the library should be
threadsafe.

Versions with an even minor version denotes a version under development,
while those with an odd minor refer to a specific release. Thus, the
version starts with 0.0 instead of 0.1.

What is needed to reach 0.1 is at least a proper working SH_Text,
without the danger of undefined behaviour and capable of serving to a
working TextFragment.

started documentation with texinfo

When artifacts are extracted, the timestamps are set to the extraction
time. This causes make to consider prerequisites, included in the
artifacts, newer then their targets, which results in an unnecessary
invocation of the associated rules. While this is unnecessary, but
unproblematic for the actual compilation, it induces problems for the
generation of scripts, macros et cetera, which depend on the
installation of maintainer software. These are only installed for
stages, where they are really necessary, to reduce the time, the
pipeline is running. Thus, when the generation is reinvoked in the wrong
stage, not only time is wasted, but the pipeline will fail.

This was previously bypassed, by invoking configure with
--disable-maintainer-mode, which prevents the rebuilding of the build
environment at all. However, this is not suitable any more, as the
generation of the documentation is also prevented by this option, which
is not envisaged.

The shell script save_timestamps.sh, which is invoked before collecting
the artifacts, retains the timestamps of the artifacts, by creating a
script, which restores them. This is then invoked after the artifacts
are extracted in the next stage.

At the moment, the artifacts are listed twice, once for the script and
the second time for the artifacts list. A solution to evade that has not
yet been found.

The same issue exists for prerequisites, which are checkout'ed freshly,
thus having the checkout time, which renders them newer than there
targets. This was already fixed in 'ci: prevent double compilation',
but the solution wasn't used in all necessary places.

It might be useful, to see, whether configure decided to run the tests.

Copied CSS from gnu.org:
reset.css: https://www.gnu.org/reset.css
style.css: https://www.gnu.org/style.css
manual.css: https://www.gnu.org/software/gnulib/manual.css

At each point, where something regarding a file is mentioned, this
position should be added to the file index. This is a bit cursed in
printable format, as is sorted by the first letter and especially the
dot (.) looks strange. Also this alphabetic order isn't really
satisfying.
However there are some quirks, when trying to the trick the indexing
system in doing something else. When it is tried to remove the grouping
by letter by grouping everything with @sortas{ }, just one entry is
appearing. If it is tried to use the grouping feature as a way of
resembling the file system with @subentry, there is first a limit of two
subentries, and secondly filenames starting with a dot disappear.