Generate proper IN nodes

I was doing this incorrectly before.  Unfortunately it requires that
nodes get renamed in place, which is a bit of a hack...
Generate random values for input nodes

Note that this is actually two changes: one fixes the input node
handling (which doesn't currently get exercised, a test case will be
added) to match Chisel's semantics, and one generates random inputs so
we can actually test dangling inputs.
Allow multiple updates on a single cycle

This matches more with what Chisel allows: essentially the last update
will take precedence.  Note that this still has C++ execution
semantics, so if you do something like:

  value->update(value_1)
  temp = value
  value->update(value_2)

then you'll end up with "temp" as "value_1".  In other words, there's
no dataflow semantics anywhere.
Allow a node to be updated from a node

This just copies the other node's value, it's really just a tiny
helper function to make pattern implementations a bit cleaner.
Add "operation & operation" operator

This does a bitwise and, just as expected.
Use "flo-llvm --torture"

This is a special mode of operation that generates VCD files that
coorespond to what Torture expects.  Essentially the idea is that
Chisel appears to generate a bunch of junk (internal registers, for
example) that we don't necessairially even know how to track with
torture.  This flag prevents those nodes from being emitted.
Use "vcd2step" to generate test vectors

This new program (from the vcd2step package I just wrote) allows me to
generate Chisel tester input files from VCD files (and the
cooresponding Flo file, which indicates which are inputs).  This way I
don't need to generate a second file format from torture, just VCD
files!
Add "one_sided_and_tree"

This is probably poorly named.  The general idea is that this just
builds a big linear AND of a single value, done many times.  Something
like

  (((in & in) & in) & in) ...

This has a few advantages: it's simple (the input is the output), it's
single cycle (all combinational logic), and it's not efficient on
DREAMER (so it serves as a test case for flo-opt).