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.

As the access must be fast, the tags are sorted when inserted, so that
the search can take place in log-time.

Instead of having one function performing all the tests, they are split
into multiple functions. Also a bug was found.

While it was very clever, the complex data structure of the tag array
introduced in 'Validator: restructured internal data (a0c9bb25)' comes
with a lot of runtime overhead. It reduces the calls to free and
realloc, when a lot of tags are deleted and inserted subsequently, but
burdens each call with a loop over the linked list of free blocks.

This is even more important, as validator must be fast in checking, as
this is done everytime something is inserted into the DOM-tree, but has
not so tight requirements for registering new tags, as this is merely
done at startup time.

To test static functions, static haven't to be declared as empty.

When a newline is encountered in the text, a <br /> is inserted and for
wrap mode also a newline and an indent is inserted. Note that the indent
is still missing at the front where it can't be inserted yet as SH_Text
is still lacking basic functionality.

The copy_and_replace function replaces a single character with a string,
while copying. This may be replaced by an elaborate function as
manipulating a text normally means that manipulating is deferred until
needed, which this function contradicts to.

What the method does is merely squashing everything together as opposed
to performing a direct copy.

At the end of the pipeline a release is generated. A release
automatically adds a tag, which in turn would trigger the pipeline a
second time. This is prevented.

The marks are now allocated and the allocated, where appropriate.

A text_segment allocates memory in terms of chunks, this is now also
done, when created from a string, but this means that we can't rely on
strdup anymore, as it takes care of the allocation. Calling malloc
ourselves shouldn't be such an overhead as at least glibc's strdup
performs the exact same steps. Actually we should be spare a strlen call
now, so it should be more perfomant.

A mark will be used to point to a specific location inside of a text.
Currently it can't do anything and isn't even used.

While it would be preferable, it doesn't seam to be possible to abstract
over the internals of text_segment. That's why only some basic
functionality is moved, but whether more is to follow, is not known yet.

Adjusted error coding style, to current one.

changed year and corrected email address

Some adjustments suggested by autoupdate and autoscan were added.

The transition from a single fragment, which is a tree, to a polymorph
fragment implemented by a base class (Fragment) and a subclass for
storing the tree (NodeFragment) and another subclass for storing text
(TextFragment) is now considered complete.
What is still missing is the proper treatment of embed text. This should
be indented and breaked at 72/79/80. Also newlines and special chars
should be replaced on generation, maybe also giving some way of
preventing XSS. Regarding the NodeFragment there should be some
adjustments to further adjust the styling, which of course should also
be reflected by TextFragment. This should also include the generation of
self-closing tags. Furthermore the html generation should be based on a
single text object, to which is added to. This will later on also enable
to directly send generated parts over the network while still generating
some data.
But all this changes are to meant to change the behaviour of existing
classes, so the will be eventually implemented on seperate branches.

The html generation for both TextFragment and NodeFragment combined is
tested. As the encoding semantics of the TextFragments are neither
defined nor implemented, some tests are marked as XFAIL.

Some basic text functionality is now directly supported via wrapper
functions.

Note that wrapper functions aren't tested in unit tests.

While this method is neccessary to manipulate the content of a
TextFragment, the TextFragment should abstract the semantics of Text.
While simple wrapper functions for appending are to be added, methods
purely manipulating the text, i.e. relying on the text's contents, wont
get wrapper functions. Thus this method is still needed until a more
sophisticated approach is implemented.

There are seperate build, test and release stages. Also the resulting
package is uploaded. To do that a special script was written to get the
real name of the package, which autoconf inserts into the scripts on
configure-time.