Diagrams/Dev/Text

See issue 29.

Issues making text support difficult:

Diagrams are scale-invariant, but text is not really scale-invariant for several reasons:
- Glyphs can be different for different font sizes
- Users might not actually want font size to scale along with a diagram, for the same reasons that they might not want line width to scale -- it requires non-local thinking to get all the sizes to match up.
Fonts are complicated.

Below is a suggested plan of attack for font support.

Phase 1

Font size is an attribute just like line width. However, in Phase 1 font size will not be affected by transformations _at all_, even in frozen diagrams. (See phase 2 below).
Text objects take up no space. To leave a fixed amount of space, text can be composed with e.g. a phantom box. Combinators can be provided to make producing such a text + phantom box easy.
Diagrams does not know anything about fonts, other than having a font attribute. Selection and rendering of fonts is left up to backends.

Allow "reification" of text into a path. Obviously this requires being able to deal with fonts. There are some issues here to be worked out re: IO/purity. (For the Cairo backend, it seems Pango can do this.)
Freezing a diagram results in reification of any text objects.
With respect to spacing/bounds:
- Explicitly reifying a text object into a path will result in a normal path with a normal bounding function.
- However, text objects which are implicitly reified into a path using "freeze" take up no space.

Text objects take up a variable amount of space, depending on the final scaling factor. Solve for the positioning and spacing of diagrams using a constraint solver.
This phase requires some sort of constraint-solving module first (issue 12).