Add proof-of-concept unix 'tree' style logger class 'UnixTree'.

Needs two improvements:

1. actually produce 'tree' style output.  This should be easy.

2. generalize constraint handling so that, for instance, a single
definition of 'f' can be logged in both 'UnixTree' and 'AllShow'
style.  Currently I've had to duplicate the definition of 'f' again.

Current proof of concept output shows that it works. Success:

  f 4 = "XXXX"
    f 3 = "XXX"
      f 2 = "XX"
        f 1 = "X"
          f 0 = ""

Error:

  f 6 = <error: there>
    f 5 = <error: here>
      f 2 = "XX"
        f 1 = "X"
          f 0 = ""
Add experimental code snippets that I might come back to later.

I will almost surely come back to
experiments/using-gadts-to-avoid-signatures.hs, although I've
eliminated the use case for
experiments/generating-unique-types-from-strings.hs (but would still
like to see if I can generate the types; using __FILE__ and __LINE__
may help ...).
CP: Add 'ConstraintLogic' module w/ constraint conjunction and casting.

I've since figured out a better way to do this, coming soon ...
Reference a work around.
Simplify 'CoerceH' example.

But next I'll give a proper definition of constraint implication.
Add constraint implication and 'LogTree' coercion.

This may be the trickiest code so far!  It was conceptually hard to
come up with an implementable definition of constraint implication (I
ended up with 2 equivalent defs!).  Once we have the definitions, it's
easy to see how they are used to write coercions, but in practice it's
hard to make the coercions type check, because they involve a lot of
careful manipulation of types, which are mostly implicit in Haskell.
So, I needed a lot of type signatures and scoped type variables, and
careful supplying of arguments to trigger type quantifier manipulation
(or at least, that's what I think is going on; e.g. writing
'implies2 impl = f impl' instead of 'implies2 = f').

Now that we have 'LogTree' coercion, it should be possible to log once
and then post process via many processors.  So, I better start
implementing more processors and logging examples ...
Rename 'Tree' to the more descriptive 'UnixTree'.
CP: Index 'LogTree's by their call type and a constructor name.

This will make processors have slightly nicer signatures (can now
refer to the constructor accepted by name), and pushing the
existential binding of 'call' outside of 'LogTree' itself (now we use
'Ex2T' to existentially bind 'LogTree' indices in 'LogForest's) may
simplify some type parameter instantiation down the road.
CP: Update 'ConstraintLogic' to work with new 'LogTree'.

I added an export list to 'LogTree', to avoid name conflicts with
internal parser functions, but what I really want is to just mark the
parser functions as *not* exported. I.e., I want a default allow with
explicit denies policy, rather than a default deny with explicit
allows policy:P Of course, there is no way to do that in Haskell that
I know of.  Here's a nice SO answer giving a middle ground:

  http://stackoverflow.com/a/17241961/470844

Namely, define a special module for imports that just reexports your
modules selectively.  Then, any user that needs to access to more
functions can just import the individual modules.  I think this is a
great idea.  The Unbound library does something like this.

Also, instead of trying to see if I could use the new 'LogTree' type
indices to simplify the 'coerceLogTree' coerciion functions, I just
added 'Ex2T' where needed.  This had the annoying side effect of
creating a composition, so I started by naming all (6!) of the
arguments:

  callAndReturn call before arg children ret after =
    Ex2T $ CallAndReturn call before arg children ret after

Then I got to thinking "maybe I can write an n-ary compose?" but it
seems it would be hard to type this without specifying names for the
'n' type varibles as input, which sounds tedious.  Also, it's not hard
to define each compose individually, up to arity 10 say, which should
be enough for most purposes.  E.g.

  o2 :: (b -> c) -> (a1 -> a2 -> b)       -> (a1 -> a2 -> c)
  o3 :: (b -> c) -> (a1 -> a2 -> a3 -> b) -> (a1 -> a2 -> a3 -> c)

etc.  The names '(..)' and '(...)' would be better, but they aren't
allowed.  Then I could write e.g.

  callAndReturn = Ex2T `o6` CallAndReturn

However, I googled a bit to see if I could find a Hackage package
which defines all these 'o<n>' combinators, and I was reminded that
they can be written point free by composing compose.  E.g.

  o6 = (.).(.).(.).(.).(.).(.)

Now, I've seen this before, but it's always seemed a little
mysterious.  I mean, it's easy to check that it's correct, but *why*
should this work? Seems like quite a coincidence! Is there some
underlying concept?  It turns out there is!

The underlying concept is functors! This sort of usage has been given
the name "semantic editor combinators" by Conal Elliot, and he has a
blog post about it here:

  http://conal.net/blog/posts/semantic-editor-combinators

Also, this SO answer is helpful:

  http://stackoverflow.com/questions/413930/haskell-how-to-compose-not-with-a-function-of-arbitrary-arity?rq=1

However, while both of those sources point out that one composes
various fmaps (and some non fmaps in those presentations), they
emphasize that it's really *all* about (co- and contra-variaant)
functors.  So, I'm going to explain it that way here, for future
reference.

The big idea is that most common n-ary type constructors are really
n-ary functors, and that by viewing '(->)' as a 2-functor we can see
how it's map lets us "edit" the domain and range of function.  Higher
order functions are just right-associated iterated applications of
'(->)', and so nested mapping lets us edit arbitrary components of
higher arity function types.

To view '(->)' as a 2-functor, we define

  fmap(->) :: (a' -> a) -> (b -> b') -> ((->) a b) -> ((->) a' b')

by

  fmap(->) fa fb f = fb . f . fa

Note that '(->)' is contra-variant in the first component and
co-variant in the second component.

Now, we can just as well view '(->)' in terms of partial applications
which give 1-functors, i.e. co-variant functor '(a ->)':

  fmap(a ->) :: (b -> b') -> ((a ->) b) -> ((a ->) b')
  fmap(a ->) fb f = fmap(->) id fb f
                  = fb . f

and so:

  fmap(a ->) = (.)

And, a contra-variant functor '(-> b)':

  fmap(-> b) :: (a' -> a) -> ((-> b) a) -> ((-> b) a')
  fmap(a ->) fa f = fmap(->) fa id f
                  = f . fa

and so:

  fmap(-> b) = flip (.)

Note that these two presentations are equivalent. I.e., we can recover
'fmap(->)' from it's unary specializations:

  fmap(->) fa fb f = fmap(a ->) fa (fmap(-> b) fb f)
                   = fmap(-> b) fb (fmap(a ->) fa f)

or equivalently:

  fmap(->) fa fb = fmap(a ->) fa . fmap(-> b) fb
                 = fmap(-> b) fb . fmap(a ->) fa

It's interesting to note that the composition order doesn't matter,
because each map is affecting a different, independent component.

Once we've realized that '(->)' can be viewed like this, the n-ary
compose becomes easy. We want to define

  o<n> :: (b -> b') -> (a1 -> ... -> an -> b) ->
                       (a1 -> ... -> an -> b')

Rewriting in terms of the '(->)' functor we get

  o<n> :: (b -> b') -> ((->) a1 ((->) a2 (... ((->) an b) ...)))
                       ((->) a1 ((->) a2 (... ((->) an b') ...)))

and we see that want to edit the second argument to inner most '(->)'.

Now, to map over a composition of functors, we use a composition of
maps.  E.g. for two co-variant 1-functors 'F' and 'G' we have

  fmapF (fmapG fb) :: F(G(b)) -> F(G(b'))

For n-ary functors it's of course more complicated abstractly, but can
consider our concrete '(->)' and map as follows:

  o<n> fb = fmap(->) id (fmap(->) id (... (fmap(->) id fb) ...))
          = (fmap(->) id) . (fmap(->) id) . ... . (fmap(->) id) $ fb

Or, thinking in terms of 1-functors, we have

  o<n> = fmap(a1 ->) (fmap(a2 ->) ... (fmap(an ->) fb) ...)
       = fmap(a1 ->) . (fmap(a2 ->)) . ... . (fmap(an ->)) $ fb

Recalling that 'fmap(a ->) = (.)', we recover the familiar

  o<n> = (.) . ... . (.)

But, from this new view point, we see that any edit is easy.  E.g.,
suppose we want to define a combinator

  c :: (a1' -> a1) -> (a2' -> a2) -> (b -> b') ->
       (a1  -> a2  -> b) ->
       (a1' -> a2' -> b'

then

  c f1 f2 fb = fmap(-> (a2 -> b)) f1 .
               (fmap(a1 ->) . fmap(-> b) $ f2) .
               (fmap(a1 ->) . fmap(a2 ->) $ fb)

and of course we may reorder three composition components as we like.

And, as mentioned, this works for most any type constructor.
E.g. pairs we have

  fmap(,) :: (a1 -> a1') -> (a2 -> a2') -> ((,) a1 a2) -> ((,) a1' a2')
  fmap(,) f1 f2 (x1 , x2) = (f x1 , f x2)

with

  fmap(a1,) f2 = fmap(,) id f2
  fmap(,a2) f1 = fmap(,) f1 id

and e.g.

  c :: (a1' -> a1) -> (a2' -> a2) -> (b -> b') ->
       ((->) ((,) a1 a2)   b) ->
       ((->) ((,) a1' a2') b') ->

given by

  c f1 f2 fb = (fmap(-> b) . (fmap(,a2) f1 . fmap(a1,) f2)) .
               (fmap((a1 , a2) ->) fb)

Hopefully by now the pattern is clear: we just nest maps, following a
path down to the component we wish to edit.  When we enter a
co-variant component we become covariant, but otherwise the levels
don't interact.

Finally, let's check that (->) is really a 2-functor, just for fun.
The 2-functor laws are:

  id:      fmap id id = id
  compose: fmap f1 f2 . fmap g1 g2 = fmap (g1 . f1) (f2 . g2)

where the type of 'compose' comes from the contra-variance of the
first component.  To check:

  fmap id id = \f . id . f . id
             = \f . f
             = id

  fmap f1 f2 . fmap g1 g2 = \f . fmap f1 f2 (fmap g1 g2 f)
                          = \f . f2 . (g2 . f . g1) . f1
                          = \f . (f2 . g2) . f . (g1 . f1)
                          = \f . fmap (g1 . f1) (f2 . g2) f
                          = fmap (g1 . f1) (f2 . g2)

Yay!
CP: Update 'UnixTree' to use 'LogTree' with more indices.

This does indeed simplify the processor implementation.  Of course, I
can only think of three processors I want to implement so far, so the
savings here are not exactly huge, but it was fun to figure out how to
make it nicer.
Update 'Test' to use new 'LogTree' with more indices.

The 'UnixTree' processor instance is arguably simpler now, since the
argument pattern matches, e.g.

  callAndReturn _ _ (arg,()) _ ret _ = ...
    ...

get replaced by projections, e.g.

  callAndReturn t = ...
    ...
    where
      (arg,()) = _arg t
      ret      = _ret t

and of course the '_ret t' for 'ret' could just be inlined.  The user
can still do the full pattern match if they want, but now the
constructor needs to be given. E.g.

  callAndReturn (CallAndReturn _ _ (arg,()) _ ret _) = ...
    ...