Introduce common interfaces (abstract supertypes) for similar types

[schillic]

Initial motivation: supertype for HPolygon and HPolygonOpt:

1. Avoid copy-pasting methods in both HPolygon and HPolygonOpt.
2. Allows to restrict a type to a polygon irrespective of the implementation.

The idea also translates to other types such as BoxSet(?) for Hyperrectangle/BallInf.

Another idea is to have different implementations of array-type sets (MinkowskiSumArray etc.) that store their dimension for faster access.

So the general message here is:
Introduce interface types and usually only work with them.
A crucial implication is that we should never access member/field variables directly (because different implementations may not have those members).
Instead there should be a function that is usually just a getter.

[schillic]

Proposal (I am open for different names):

ZeroSet, Singleton <: SingleSet  # provide: element(dim), element
HPolygon, HPolygonOpt <: HPolygonal  # common: many methods
HPolygonal, VPolygon <: Polygonal  # provide: tovrep, tohrep; inherit: dim
SingleSet, BallInf, Hyperrectangle <: Box  # provide: radius_b(dim), radius_b
Ball, Box, Zonotope <: PointSymmetric <: LazySet  # provide: center; inherit: dim
Ball1, Box, Polygonal, Zonotope <: Polytopic <: LazySet  # provide: vertices_list

[SingleSet, Ball1, Ball2, Ballp, BallInf <: Ball] -- removed for simplicity

radius_b should not be confused with the existing radius for general LazySets.

[schillic]

Another possible extension is to have implementations for "centered in the origin" sets such as a Hyperrectangle0. These are more efficient to store and process (no center).
If we want this, we should introduce another layer of abstract types for each concrete type. Then we can provide different implementations for the same concepts. We already have this for HPolygon and HPolygonOpt.

We do not have to implement such sets right away, but with these changes this will be straight-forward to integrate them later.

[schillic]

Noooo, Julia does not support multiple supertypes (yet).

One can simulate multiple (abstract) supertypes with artificial combination types of course. Maybe I will just do that... 😈