Add Diagrams.Anchors

[bch29]

Moving this to diagrams-contrib instead of diagrams-lib as suggested. Original pull request.

First up, thanks for having a look at this! It's no problem that it took a while, I have no urgent need to get this merged.

To answer the comments in the last post there:

• My main reasoning for having a separate Anchor type (and associated class) is that when qualifying all the anchors in an object, it might be annoying for all the other names to be qualified too. I suppose an extra operator could be provided that just qualifies the anchors and not other names, in addition to the standard (.>>). But then there's the issue that some might want to qualify names but not anchors... In general, it seems to me that anchors serve a different enough purpose from names to warrant their own type.
• I struggle to understand what assigning anchors to points would actually mean. In my current implementation, vectors are used as offsets from the local origin of the object having anchors applied to it. How is a point different in this context? Is a point an offset from the global origin? Why would such points be useful as anchor locations? As for doing something more sophisticated with envelopes, I agree that this would be useful and I'll see about implementing it when I get the time.

[byorgey]

• Re: having a separate Anchor type, OK, that makes sense. I was just trying to see if there was a way to reuse any machinery we already have around Names, Qualifiable, etc., but I think I agree with you now that they serve different purposes and should be kept separate.
• Sorry, I don't think I was clear before. Anchors should still be represeted as vector offsets from the local origin. All I meant was that there should be more functions for making anchors in addition to withAnchors and addAnchor. For example, there might be variants of withAnchors and addAnchor that take points instead of vectors; they would work in the obvious way, by subtracting the origin from the given points to come up with the required vectors. Likewise there could be e.g. variants that take vectors but interpret them as inputs to the trace, instead of using the given vectors directly.

[byorgey]

I think the Travis build is failing because you need to add a DeriveDataTypeable extension.

Also, to be clear, my suggestions re: more variants for withAnchors and addAnchor are just suggestions for improvement, not requirements for merging. I can merge it as soon as the Travis build is fixed, and we can continue to improve it.

[byorgey]

Closer, now it only fails on GHC 8 because of some redundant constraints:

src/Diagrams/Anchors.hs:99:10: warning: [-Wredundant-constraints]
    • Redundant constraints: (Additive (V t), Num (N t))
    • In the instance declaration for ‘Transformable (Anchored t)’

src/Diagrams/Anchors.hs:122:10: warning: [-Wredundant-constraints]
    • Redundant constraint: Show (N t)
    • In the instance declaration for ‘Show (Anchored t)’