extend and factor out twining code

[kfjahnke]

Having worked with the twining 'meta filter', I get the impression that the method is very powerful and versatile. It may be a good idea to decouple twining from the remainder of the code and make it into a stand-alone library. It would need only zimt as a dependency. It may also be a good idea to move the twining code to the zimt library, which as already accreting a fair amount of collateral code. The base idea is similar to what I proposed as 'meta filter' in vspline (see https://bitbucket.org/kfj/vspline/src/master/example/metafilter3.cc), but the twining code is more efficient, because it does not require rotation operations on the coordinates.

The twining code generates the basis vectors for the sub-pick-ups from two additional target coordinates calculated from two 'canonical' neighbours, optionally projected to the tangent plane for mathematical correctness (which is usually overkill, so it's optional, see --twine_precise). Is there maybe a better way to obtain the derivative? I also think that maybe reducing the width of the 'canonical' step to, say, 1%, may approach the derivative better, making the projection to the tangent plane even less necessary.

Additionally, providing a 2D version of the twining code would be nice. For both the 3D and the 2D case, an alternative route of parameterization might directly provide the basis vectors. This may be even more versatile and allow application code to come up with it's own ways of generating the basis vectors, rather than relying on the 'canonical neighbours'.

[kfjahnke]

the code now uses two sub-pick-ups to obtain the 'derivative' which are so close to each other that they 'land' in the same source pixel. the actual distance is picked with mathematical stability in mind - no need to push it too far with lowering the distance, but nice to be proof against certain unwanted effects due to the sub-pick-ups landing in different pixels (e.g. when looking at cubemaps)