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.

Useful in combination with the AssemblyInformationalVersion property.

Otherwise git will complain about binary diffs.

See https://stackoverflow.com/a/10334095/2018314 for details on sharing
resources among multiple projects in a solution.

The second colon (:) has strange effects in the "Output" window of
VisualStudio, messing up the text alignment.

There is no need to have this only as a post-build event, providing it
at this stage will allow us to include it in the assembly information.

With this commit all required changes for having the configuration in
two separate files should be completed.

Fixes #18

Refers to #18

Closes #28

Refers to #18, #28

Refers to #18, #28

Refers to #28

This way we can handle the situation in the calling code, e.g. sending
an email notification to the admin address.

Locating the update package is now done in Find-InstallationPackage and
stored in $UpdPackage, so we can safely remove the redundant code. In
addition, this change makes the function return $True or $False,
depending if the copy action succeeded.

Refers to #28

Refers to #18, #28

After validating the config files we can now safely trigger the update
if necessary.

Refers to #18, #28

No checks are done in Update-Configuration any more, as the control
logic has been changed to do those beforehand now. Therefore also
Update-File is not comparing the write-times any more nor terminating
the script if something fails (now returning $False instead).

Refers to #18, #28

Instead of terminating the entire script immediately we log a message
and pass on success / fail so the remaining script logic can deal with
the situation.

Refers to #18, #28

This adapts the updater to the new configuration locations (#18) and
changes the control flow so that first the script will detect if any
updates are necessary at all and then validate the configuration files
(respecting what parts will be updated), preparing for the actual update
tasks (as this is currently work-in-progress, those update tasks are
disabled for now.

Refers to #28