The shared approach results in conflicts if the generated class is used
in ATxCommon which is imported in the other projects. This way we can
use the symbols defined via ATxCommon in all depending projects.

The downside is that it slows down the build-process a bit as every
build from a project depending on ATxCommon (read: all others) will
change the generated code and thus force a re-build of ATxCommon and
the project itself. Since building the entire solution is still just
a matter of seconds, that's a fair trade-off.

Refers to #18

Refers to #18, #29

Refers to #18, #28, #29

Refers to #29

Refers to #28

Refers to #28

Refers to #28

Those objects are not meant to be instantiated directly but only using
the Deserialize() methods which takes care of creating a new object in
case deserializing fails for the status class.

This way the value is directly visible in the code where the property is
created, improving readability. Setting defaults in the constructor is
therefore not necessary any more.

Refers to #29

Refers to #18, #28

Refers to #29

Refers to #29

Refers to #29

Refers to #29

Refers to #29

Again, no functional changes in this commit!

Refers to #29

Plus, group them in a logical sequence instead of a type-specific one by
following the order being used in the new example files.

This commit should not introduce any functional changes!

Refers to #29

One file ("config.common.xml") containing site-global configuration
settings, the other one (the file name equals the host name with a
".xml" suffix) containing host-specific settings.

Both files use the same syntax and may contain the same setting
attributes with the host-specific one having priority over the
site-global one.

Refers to #18

Refers to #24

They are already set by the XmlSerializer class to the default value of
the corresponding data type.

Refers to #25

In this case return "never" instead of calculating the delta.

Refers to #25

Refers to #24