* Boxes.elm: simple, static app that displays boxes which can be nested
* Boxes.elm: dynamic version: switch from one active box to another

Things I learned: This is my first take on the idea of having an
"active" element.  The active element is represented using a
signal (created as an Input) containing an integer id.  Next up:
growing the possible active elements dynamically.
* Boxes.elm: dynamically add activatable boxes

Things I learned:

The general problem I was having trouble solving was: how do I update
a value based on *two* parameters when only *one* of them updates?
For example, I wanted to update a list of boxes by adding a new box
when a button was clicked.  Adding a new box required the previous
value of the list, to compute a unique identifier for the new box.
But it also required an incoming signal from the button.  So two
signals need to be involved here: one representing the value of a list
of boxes, one representing button clicks.  The problem is figuring out
how to update the list of boxes, based on the previous value,
when *only* the button click signal changes.

lift2 does not seem to work in this scenario, I think because the
output signal only updates when both input signals change (not sure
about this, though...I just know I tried it and it failed).  Or at
least, lift2-ing a function f a b whose output value only depends on
b (boxes) does not update the value when only a new a (click) is
given.

The solution I came up with was using foldp.  With foldp, I could make
the signal representing the list of boxes update based on both its
previous state and the signal from the button.  This gave me an
intermediate signal, pdBoxes, of type Signal [Box] but updating on
button clicks.

This was also the first time I found it useful to have intermediate
signals, i.e., signals which I didn't construct directly with input
and which I didn't use directly in main.

Finally, I found I could use lift2 to combine the signal representing
the list of boxes with the signal representing the active box to
create the signal for the main scene.  Not so sure why lift2 seems to
work here but didn't in my previous attempts. I think it's because, the
way I'm using it here, the output value changes whenever the first
input changes (since the output is just a tuple of the first and
second inputs).  Before, I was just throwing away the first value
because only the second value was needed to compute a new output.

The code ain't so pretty, but I solved the hard problem of dynamically
updating a list based on both its previous value and on user input,
and it works!