- think about using MooseX::Params::Validate for Vector coercion in
  PositionSelection; it might also come in useful if I allow Point
  objects in these methods
- operator overloading:
  - x for intersection
  - . for point on PointSet object
  - >> for translated point
  The question is if this should return the derivate object or a
  list of derived points. The problem with the latter case is that
  styles, labels, and position selectors cannot be set. However, in
  the former case, it would only be syntactic sugar. My best bet at
  the moment is to allow default styles/colors and hidden status and
  go with the second alternative. Still, in many cases one will need
  to use the more verbose method form.
- PointOnCircle
- label positioning
- PointSet labels via PointOn points
- Can't I move positions from Circle/Line to PointSet? There might
  be classes that need it and do not consume PointSet, but is this
  really a counterargument?
- I don't like that points get there size from Construction at first
  use and then stick to that value. I think they should rather ask
  for the default value when needed, but not keep it.
- I need a clear concept of which return values can be undef and how
  to react to that (specifically where to croak and where to return
  undef).
