Attempt to detect whether to launch of_01

We used to always launch of_01 (the OpenFlow 1.0 task) unless --no-openflow
was passed.  We now only do this if we notice that someone has checked for
or used core.openflow.  Note that openflow always loads in any case, it's
just a matter of whether of_01 does too.

In some cases, this may mean you need to put openflow or of_01 on the
commandline explicitly where you didn't used to.

There's actually a more radical patch which makes autoloading generic,
which may eventually get mainlined, but this commit is simpler and can be
seen as just a step toward ensuring that older components get updated to
do the right thing with respect to launching openflow/of_01.
l3_learning: Use listen_to_dependencies()

I think l3_learning predated listen_to_dependencies() and had never been
updated to use it.  The way it handled startup meant that it didn't
trigger the automatic starting of of_01 and you'd have to do it manually.
core: Update version info
recoco: Remove some dead wood

If this stuff ever worked, it certainly doesn't now!
boot: Initialize core later

We now initialize core during the boot process rather than on import.
This requires a couple other tweaks for things which expect it to exist.
core: Make version info class attributes

Previously these were instance attributes.
recoco: Add unthreaded mode for SelectHub

Previously, SelectHub always ran in its own thread to put it on exactly
the same footing as any other IO loop.  However, this has a performance
penality, multiple IO loops have rarely been used in practice, and in any
case, SelectHub is probably special.

This patch adds the ability for SelectHub's functionality to be run
directly in the scheduler thread.  It is similar in spirit to changes to
SelectHub which are lumped into ed3b14b3c0 in the debugger branch, but
reuses more code, refactors part of the scheduler to be cleaner, and will
hopefully work correctly even with multiple threads.

Note that the old behavior (hopefully unchanged) is still the default.
This is pretty experimental.
Add commandline argument to select unthreaded SelectHub

The previous commit added an unthreaded SelectHub to recoco.  This commit
lets you enable it from the POX commandline with the --unthread-sh option.

This is all still pretty experimental. :)
forwarding.hub: Add reactive hub mode

forwarding.hub --reactive now gets you a reactive hub.
telnetd: Try harder to initialize curses

We actually don't care about setting up curses -- we're not going to use
it. We just want it to initialize its datastructures and stuff.  I don't
know of a way to do this besides calling setupterm(), though.
Unfortunately, this can fail when sys.stdout isn't as expected.  We now
try a bit harder by falling back to sys.__stdout__.  This isn't a great
solution.
telnetd: Don't hardcode prompts for Python personality
recoco: Add ability for BlockingOperations to not give up control

This has been one of those obvious good ideas which just never got
implemented until now.  This allows a BlockingOperation's execute() to
return True, which means that the scheduler shouldn't cycle, but the
same task should just be executed again.  There are a number of places
where this might be used in the existing code (where instead it just calls
fast_schedule again on the same task).
recoco: Add Lock

This is a Lock with fairly Pythonic semantics.  It can serve as a
demonstration for implementing other synchronization primitives (e.g.,
conditions).
boot: Reuse existing core object if any

This is to allow for externally created core objects to be reused rather
than trying to create a new one (for embedding POX).
recoco: Change behavior of unstarted relative Timers

Previously, the initial firing time of a relative-time Timer was computed
in the constructor.  When the timer is started some time after it's
created, this probably doesn't yield the expected behavior which is for
the timer to go off relative to the time it was *started*, not relative
to the time it was *created*.
recoco: Assert that Task's run() is a generator

Task's run()s are supposed to be generators.  If they're not, you're
probably not getting the behavior you want.  There *may* be an exception
to this (when a run() conditionally wants to end immediately), but at least
for the moment, we assert that they're generators.
messenger.tcp_transport: Reorder classes

This puts TCPConnection ahead of TCPTransport to fix a dependency problem
in a forthcoming commit.
messenger.tcp_transport: Clean up imports
messenger.tcp_transport: Make connection class settable

You can now pass a specific class into TCPTransport (defaulting to
TCPConnection).  This allows you to create and use subclasses of the
normal TCPConnection.
messenger: Added ConnectionOpened event

This new event on the Messenger nexus fires when a new session/connection
is established.  This required existing transports to be modified to
notify the nexus when this occurs.