Also restructure files containing interfaces.

- Reformat styles

This way elements can handle their logic themselves without having to
rely on outside utility classes.

Also restructure files in common in a more logical way.

Components with bigger scope are put to the component root, canvas, 
props panle and new-element-panel.

Change import paths of CommonModule files in editor and player

The solution is to always show the section menu of the selected section. 
No more hovering shenanigans.

#223

Don't use the page maxWidth when it is not set.

This is now done only via the cdkDropListGroup directive which collects 
child drop lists. There is actually no need to connect them manually.

- Units and element are now built via the factory. This ensures only the
  wanted properties are present. All others are discarded.
- Since the sanatizer is supposed to check the unit defintion version
  it is used by player and editor and therefore put in common.
  This in turn makes it necessary to put the JSON resolver settings
  in the root-TSConfig file.
- Renamed a couple of properties to have clearer names.

This removes all the classes and goes back to simple interfaces for
unit, pages etc and all elements. This makes creating them easier and
cleaner.
Things like specific needs when setting element properties and most
importantly compatibility handling is done by a special service module,
that knows all the elements and how to repair old their potentially
outdated definitions.

This is done according to the Angular best practices and minimizes
namespace collisions when using other packages which might use the same
selectors.

Technically the selectors are not even becessary since we use an Angular
component factory to create element components but it is still useful
for the DOM element naming, for debugging purposes for example.

The dropListList generation is now done when things are changed via the 
section menu and no longer on element update via unit service.
Also remove some interfaces to avoid circular imports. The interfaces 
are so small and insignificant that their form might as well be 
specified at usage point.

This allows to select elements without clicking them on the canvas, as 
elements may be obstructed or not visible for some reason.

The selection logic is a bit complicated because usually only the 
overlay components are usd for selection which are also the place to 
apply any highlighting on. Here we have to find the component element 
reference from the section. Therefore the double looping 
'getElementComponent' method.

Also when an elements is selected it briefly gets z-index 100 so it is 
moved to the front and visible and manipulatable.

The problem being solved is that compound-sub-elements must not have
all the properties other elements have. For exampe positioning info.
Sub-Elements are positioned inline. To avoid having similar class
inheritance structures for positioned and inline elements, we use
interface. Positioning is done via interface and is therefore optional.

Those optional properties are kept in an object in a variable. This
allows to hide specifics from element classes and removes the need to
initialize all the fields in every class using the interface.
The elements mostly care about their own specific properties anyway.

The same technique is used for font and surface elements. Here we also
don't want to initialize all the styles in every class.

Changing values of element properties works like before. Just set the
property as if it would be a direkt prop of the element. The element
itself puts the value in the currect sub-object (positioningProps,
fontProps etc).

For reading the values there is a similar method, but it is not used
anywhere by now. Since the properties panel operates on the raw values
anyway (refer CombinedProperties) and for element components this would
mean calling a function in the template, which caused change detection
to run the function very often and is therefore bad practice.

Additional notes and refactorings:
- Restructure all files in common. UIElements in the same folder etc.
- Move all interfaces to the UIElement file. This avoids circular
  imports, which would be needed to allow PositionedElement to extend
  UIElement.
- Interface initializers also handle reading values in the old form.
- Add PositionedElement for use in canvas overlays. This is a UIElement
  with guaranteed postionProps.
- Don't export all Material packages from common, only the ones
  used in player and editor. The rest is only used in common and
  does not need to be exported.

This structure moves closer to the structure template the team decided
on. Components and services are kept in dedicated folders instead of
following the logical code structure. This is still not the case here as
the unit-view component is still nested, but it's closer.

Was missing margin at the top.

Use proper types and remove unused vars.

The main components are right at top level and the directories below
mimic the data structure (unit->page->section).
The toolbar is only used in dev mode and does not belong directly to the
unit view.
The TextEditor is a complex component and deserves it's own directory
even though it is used within the unit-view. Might be refactored to its
own module later.

Can now be repositioned and moved between sections properly.

- The selection service only needs to handle element selection. For
pages and sections having the index is enough.
- Those indeces are simple fields instead of observables. This also
simplifies the components which don't have to get the value out of the
observables.
- Therefore the selection service does no longer need to have a direct
reference to the unit service and it's unit.
- Selection logic is not done by the section components themselves but
by the parent canvas component.
- The unit service can now manipulate pages and section by index in
addition to passing the necessary objects directly.

New elements are now put on the current(/newly created) page or section.

The section menu (containing all former properties options and
reordering) is now shown on section hover.
- With the removal of the section edit mode the view-only elements
are no longer needed, as sections can no longer be dragged.
- The unit service now has a unified logic for moving items in an array,
being used for pages and sections. Although for pages there is an
additional regarding the always shown page.
The reorder function silently ignores nonsense reorders!
- The prompt dialog now takes the text as parameter

They are now modified via menu at the section and no longer via props 
panel.

To make it work that the section itself can handle drop events, but
also have the canvas to handle drops when outside of the section, all
the allowed dropLists have to be connected. Because the lists are not
properly nested (see below), this needs to be done manually by IDs.
This list is given to the necessary dropLists to make it possible to
drop items not only into them but also any other connected dropLists.

Dynamic sections have droplists for the grid cells next to the actual
elements. Elements can not be children of the grid cells because they
can span over multiple cells.

Dynamic sections don't have a general drop area, like static sections.
They have grid placeholder elements which are droplists. Therefore they
have no parent dropList to add to the list but themselves.
Static elements only have the parent, which is added to the list.

Resizing in dynamic sections is handled by the section/element-overlays
themselves.

Ticket #38

When this is set the page will only be rendered to that width. Otherwise 
100% of the available space is used.

In this mode sections can be inserted, reordered and deleted with 
buttons directly on the canvas.

The section now always has the same width as the page (minus margin).