Started to develop Math::Geometry::Construction::Vector

Things to think about:
- How does this affect changing of values e.g. in
  FixedPoint::position?
- Should I allow mutation of provider? Probably yes.
- In FixedPoint it looks like I am handing over position issues to
  Vector.
  - Is this going to be a general concept?
  - Is there a more elegant way using Moose's 'handles' or so?
docu enhancements
Vector::provider is rw

Thought a lot, did almost nothing. Still unsure how to handle
things, especially with respect to buffering
FixedPoint works with Vector
working on Point coercion

I have to think about how to avoid that the center Point of a circle
gets autogenerated twice; maybe via a builder method for the
automatic support point in case of a fixed radius. Some how the
support point must be generated after the center has been coerced
into a Point.
Fighting with Circle

This is a bigger problem, though. The coercion into Points is
difficult because Point requires the construction attribute.
circles work

I have decided not to coerce into Points. It would be nice, but it
also generates quite some problems:
- The coercion does not know the construction object.
- The using attribute supports FixedPoints and DerivedPoints, but
  should coerce other values into FixedPoints. This can get messy,
  at least for someone with my Moose experience.
function name change, that's all
Removed some useless tests

This is not a complete audit of this test script (which might in
fact be required).
removed the boilerplate tests

This should be done somehow with Dist::Zilla.
refactored generation of order_index

The difficulty here is that the construction of an object might
trigger the autoconstruction of other objects before the higher
order object is registered with the construction object. Therefore,
count_object will not return the correct number of objects, yet.

Still, the old way where the order_index generation was decoupled
from object construction was not very clean. Specifically, I could
not make order_index a required attribute. I have solved this by
introducing an explicit counter attribute in Construction. Whenever
you ask for counter it is atomically incremented.

This means that order_index does not implicitly reflect the number
of objects. Right now, the numbers are still incremented along each
other, but if it becomes possible that object creation is aborted
(after add_object has been called) then counter has been
incremented, but the object never gets registered. However, it has
never been claimed that order indices go hand in hand with the
number of objects.
Merge branch 'refactor_order_index' into towards_0.024
predicate and clearer made private

...as recommended by Moose best practices
Vector coercion in PositionSelection

I use MooseX::Params::Validate in order to coerce vector sources
into a Vector. The import_vector method thereby has become obsolete
and has been deleted.
IntersectionLineLine works
IntersectionCircleLine works
all Derivates updated

base class has no input attribute any more
Merge branch 'specific_input_for_derivates' into towards_0.024
PointOnLine works with AlternativeSources role
adapted PointOnCircle