The demo program now uses some of the new functionality.

Instead of the trivial structure SH_Error, SH_Status is used. The name
was chosen, because error/status is set independently whether an error
has occurred. Beside the error type, it also contains the associated
errno and an error message. The error message is also printed, when it
is set. Generating error messages with variadic arguments is now also
supported.
There are also macros to check for a set status.

The exception handling was removed for the *_free methods, because they
can't fail predictably during runtime.

Unfortunately the compiler reports, that inside the macro set_status
printf may be called with NULL [printf (NULL)], although, this is
explicitly debarred.

The make process was restructured to create a library. For this libtool
is used to provide both static and dynamic linking. Also header
inclusion guards were introduced, to prevent clients of the library to
include some single file without including others. The types were
exported with forward declarations for better abstraction. When
compiling the library, the macro LIB_SEFHT_COMPILATION is defined and
symbol declarations are exported fully. For compiling the tests this
macro is also defined, as the tests not only tests the API, but also the
internal state, because a lot of errors couldn't be detected otherwise.

The method SH_Text_print just prints the whole string to stdout.

The function SH_Text_get_string returns a substring of text beginning at
index and of length offset. If index is out of bounds, NULL is returned
and an error is set. If offset is out of bounds, the existent part is
returned. Also the length of the returned string can be set (optionally)
to the out parameter length.
If the original behaviour of SH_Text_get_string is achieved,
SH_Text_get_string (text, length, error) has to be changed to
SH_Text_get_string (text, 0, SIZE_MAX, length, error). The only
difference will be that the function won't fail, when the text is longer
than SIZE_MAX, because it is told to stop there. A text that is longer
than SIZE_MAX is not possible to be returned, but that wasn't possible
at anytime. Also I don't think handling char[] longer than SIZE_MAX is
possible with the standard C library. Those in this case the text can
only be returned in parts (By now only possible till 2*SIZE_MAX-1 with
calling SH_Text_get_string (text, SIZE_MAX, SIZE_MAX, length, error))
or has to be manipulated using the appropiate SH_Text methods, which are
not implemented yet.

A method was added, that returns the generated text.

This renaming is neccessary, as the future Fragmment will be the base
class to all Fragment types.

When the wrap mode is used, after each tag a newline is started. Also the
html is indented, which can be configured by the parameters indent_base,
indent_base, indent_char. The parameter indent_base specifies the width
the first tag should be indented with, while indent_step specifies the
increment of the indent when switching to a child tag. The character,
that is used for indenting is taken from indent_char. (It could also be
a string longer than a single character).
This aguments can't be set by the user, but are hardcoded (by now).

A Fragment can contain childs. When building the html, the childs html
is generated where appropiate.

Error handling is done by passing an Error structure as inout parameter
to functions that can fail on runtime predictable. This parameter is
always the last one. Methods, where this is not the case, doesn't have an
error parameter.
When an Error is detected, also an ERROR is passed to the log. Because
this isn't implemented yet, it is replaced by a nop.
The macro EXIT becomes now useless. It was used earlier in case of an
error, to terminate the program in the first place. This behaviour is not
userfriendly, but it can't be decided on the library's side, whether
there is an option to inform the user, something must be cleaned up or
even that recovering is possible at all.
Often these recognized errors are a non-working malloc or an over-/underflow.

Error handling can be ignored by the caller by passing NULL to the Error
parameter. Whether an error had occured, is also always possible to be
determined, by examining the return value. If the error occours in a
function returning a pointer, NULL will be returned. If it returns an value,
a special error value of that type is returned, i.e. PAGE_ERR in
SH_Data_register_page. If the return type would be void, a boolean is returned,
which tells, whether the method has succeeded.
(False means, that an error has occured.)

The error may have occured in an intern method and is passed upwards (the stack).
Internally errors are handled by an enum, but this must be considered an
implementation detail and can be changed in later versions.
It is in the responsibility of the caller to recover gracefully. It has
to be assumed that the requested operation have neither worked, nor
actually took place. Those the operation can be retried (hopefully).

Pages are hold by Data, CMS passes trough the call(s).

cms will be the base "object", that performs all neccessary actions.