Slots now carry around ways to show their defaults

Previously it'd be difficult to summarize a tree and carry along defaults.
Each default value could be of a different type and thus we couldn't make a
homogenous list and if we made a heterogenous list then we'd lose the
ability to show the defaults.

To remedy this the Slot interface has been changed so that it always has a
chance to provide a String representation of the default value---either
through that value's Show instance or by explicitly providing it using a
lens.
Provide the ASlot interface for heterolist [ASlot]

Normally if we want to summarize a Env.Parser value then we'll end up with a
list of Slots, but this is an invalid type since we'd really want

    [forall a . Slot a]

This is essentially the interface provided by the ASlot type. Further, we
use a few typeclasses to make it easy to access the information about Slots
or ASlots in the same way.

In order to provide this Slot-agnostic interface we introduce the X type---a
simple existential context.

All of this machinery could probably be massively simplified. It probably
should be too... Is there any reason at all to use X? It seems like it's
*always* an overly complicated method.
Massive simpl of ASlot interface

Sure it feels like an existentially type part of the system, but really
we're *completely* forgetting about the default values when we analyze
the system, replacing them by their String-show representations, so
instead we'll just call

    type ASlot = Slot X

where X is just unit but with a hidden constructor---it's impossible for someone to do anything besides pass X around, we've certainly forgotten about the default value.

    aSlot :: Slot a -> ASlot
    aSlot = fmap (const X)
Added some documentation powers to Slot

In particular, a wl-leijen pretty printer. It'd probably be a good idea to
transition this to `pretty` to remove some extra dependencies.
Merge pull request #1 from tel/feat-slot-show-defs

Slots now carry around ways to show their defaults