When an error message is allocated on the heap, it can't currently be
freed properly, because nearly every message is allocated at compile
time. There also isn't the possiblity to set a flag, because it can't be
relied, that status is defined on the callee's side. Thus, the only
method to deal with this is by freeing it by the caller, when he knows,
that the message is allocated on the heap.

fixed leaks

The type predicate was missing.

Validator is now capable of storing types for the tags, which is needed
for the html generation, as well as handling attributes.

Plain newlines are not shown in the description.

The library was always recompiled, even if it has already been compiled
in the previous stage, because on git checkout the files get the
timestamp of the checkout-time, but the already build files, coming from
artifacts, have older times, thus resulting in a recompilation.
This is fixed with setting the timestamp of every file to the last
change git knows of.

Changed code to some new conventions.

The initialisation can now be provided by the validator itself.

Tags according to:
https://html.spec.whatwg.org/dev/indices.html#elements-3

Types according to:
https://html.spec.whatwg.org/multipage/syntax.html#elements-2

Retrieved 04. 10. 2023

As there is no longer a need to override SIZE_MAX, it can be linked
against the objectfile.

Other predicates may follow.

Each tag has a type as defined by the html spec. This must be provided
on registration. Implicitly registering tags, when an attribute is
registered can't be done anymore, as the type information would be
missing.
The added parameterin register_tag, as well as the change of behaviourin
register_attr has broken a lot of tests, that had to be adjusted
therefor.

As the demo program uses tags, that aren't currently known as valid, it
became broken, by enforcing valid tags.

This commit reverts '1e61c23e'.
NodeFragment now uses the validator to validate the tags. The attributes
aren't validated yet, as this is more complicated, because the tag is
needed for that.

The two predicates SH_Data_check_tag and SH_Data_check_attr are a
wrapper to the appropriate methods of the validator. These are needed,
as there shouldn't be direct calls to the internal structure of SH_Data.
The modifying methods are not exposed, as the validator shouldn't be
changed while others depend on it.

The method names are now also unique.

Deregistering a global attribute normally is not possible, as basically
every other tag has to be added. This was implemented now.
Originally it was intended to provide the caller with the information,
that a global attribute has to be converted into a local one before
removal. However such internals should not be exposed to the caller. As
it stands there is no real reason to inform a caller, whether an
attribute is local or global. Also, there is a problem that the
predicate is burdened with the possibility, that the attribute doesn't
exists, thus it can't return a boolean directly. Both is why, the
predicate isn't added yet.
Also a bug was detected in the method remove_tag_for_all_attrs. It
removes an attribute while also iterating over it, thus potentially
skipping over some attribute and maybe also invoking undefined behaviour
by deallocating space after the array.

Global attributes are represented by empty attributes. A global
attribute is an attribute, that is accepted for any tag.
It is refused to remove a specific tag for a global attribute, as this
would mean to "localize" the tag, thus making it not global anymore.
The method to do that and a predicate for globalness is missing yet.

Some bug was found: realloc may return NULL, if size is 0.
This should not be considered as if realloc has failed.

Similar to the tags, the attributes can be initialized. Missing tags are
automatically added. The declaration syntax is currently a bit annoying,
as the tags, that belong to an attribute, either have to be declared
explicitly or a pointer to the tag declaration must be given, but then
only concurrent tags are possible.
Support for global attributes is likewise missing; it must be ensured,
that (tag_n != 0) && (tags != NULL). Otherwise validator will be
inconsistent and there might be a bug.

In preparation for also adding attributes this way.

For a rationale, see commit 'Validator: removed ids for attrs'

In preparation to the entire removal of ids, the method for removing
tags, was rewritten in order to avoid depending on them.

Originally the ids were intended to be useful for linking different
information together internally, and for providing references
externally. However, they weren't used internally, for this, pointers
seamed to be more useful, as they also allow to directly access the data
and also have a relation defined.
Regarding reference purposes, they aren't really needed, and it is more
convenient to directly use some strings, and they aren't more
performant, as there still have to be internal checks and looking for an
int isn't more performant, then looking for a pointer.
Also, they have to be stored, so they need more memory and also some
code, to be handled.

The loops as they were written would overwrite the whole array with a
single value.

The Validator can check if a attribute is allowed in a tag. It does so
by associating allowed tags with attributes. This is done in that way,
to support also attributes which are allowed for every tag (global
attributes), but this is not yet supported. So some functions allow for
NULL to be passed and some will still crash.

The predicate SH_Validator_check_attr returns whether an attribute is
allowed for a specific tag. If tag is NULL, it returns whether an attr
is allowed at all, not whether it is allowed for every tag. For this
another predicate will be provided, when this is to be implemented.

The method SH_Validator_register_attr registers an tag-attr combination.
Note, that it will automatically call SH_Validator_register_tag, if the
tag doesn't exist. Later it will be possible, to set tag to NULL to
register a global attribute, but for now the method will crash.

The method SH_Validator_deregister_attr removes a tag-attr combination
registered earlier. Note, that deregistering a non existent combination
will result in an error. This behaviour is arguable and might be subject
to change. When setting only tag to NULL, all tags for this attribute
are deregistered. When setting only attr to NULL, all attrs for this tag
are deregistered. This might suffer from problems, if this involves some
attrs, that are global. Also this will use the internal method
remove_tag_for_all_attrs, which has the problem, that it might fail
partially. Normally when failing all functions revert the program to the
same state, as it was before the call. This function however is
different, as if it fails there might be some combinations, that haven't
been removed, but others are already. Nevertheless, the validator is
still in a valid state, so it is possible to call this function a second
time, but it is not sure, which combinations are already deregistered.

As the attrs also use the internal strings of the tags, it must be
ensured, when a tag is deregistered, that all remaining references are
removed, otherwise there would be dangling pointers. Note, that for this
also remove_tag_for_all_attrs is used, so the method
SH_Validator_deregister_tag suffers from the same problems listed above.
Also if this internal method fails, the tag won't be removed at all.

Furthermore, the tests for deregistering a tag are still missing.

A attribute can be deregistered by calling SH_Validator_deregister_attr.
Note that deregistering an attr, that was never registered is considered
an error, but this may change, as technically it is not registered
afterwards and sometimes (i.e. for a blacklist) it might be preferable
to ensure, that a specific attr is not registered, but it is not clear
whether there should be an error or not.
Also the deallocating of the data used for an attr was moved to an extra
method, as this is needed in several locations and it might be subject
to change.

The Validator also contains information about supported attrs. Currently
they can't be initialized by a spec. Also it can only be queried whether
an attr does exist at all and not whether it is supported in combination
with a specific tag. The tests are missing.

There is a method to add a set of tags to a validator on initialisation.
First this removes a user application from the burden of maintaining the
html spec and also is more performant, as a lot of tags are to be
inserted at once, so there aren't multiple allocation calls.
As the validator needs the tags to be in order, the tags must be sorted
on insertion. Of course it would be easier for the code, if the tags
were already in order, but first there could be easily a mistake and
second sorting the tags by an algorithm allows the tags to be specified
in a logically grouped and those more maintainable order.
For the sorting, insertion sort is used. Of course it has a worse
quadratic time complexity, but in a constructor, I wouldn't introduce
the overhead of memory managment a heap- or mergesort would introduce
and in-place sorting is also out, because the data lies in ro-memory.
Thus I choose an algorithm with constant space complexity. Also the
'long' running time is not so important, as the initilization only runs
at startup once and the tags are not likely to exceed a few hundred so
even a quadratic time isn't that bad.

Double inclusion accompanied with macro guards are a bit ugly in
comparison to a separate file.