Don't fall thru to Hydra::View::NARInfo

This caused exceptions like:

  Caught exception in Hydra::Controller::Build->view_build "writing to file: Broken pipe at /nix/store/ihdb3widsq1dk7sbl5vqjxfcxb5ypad4-hydra-0.1pre1297-8158093/libexec/hydra/lib/Hydra/Controller/Build.pm line 59."

because the connection to the Nix daemon would be terminated due to a
protocol violation (calling queryPathInfo with an empty string).
Allow manually scheduling disabled jobsets for evaluation

Signed-off-by: Shea Levy <shea@shealevy.com>
hydra-evaluator: Respect triggers of disabled jobsets

Signed-off-by: Shea Levy <shea@shealevy.com>
reproduce.tt: Add --help flag

And a --dir flag to override the directory where inputs etc. are
stored.
reproduce.tt: Check for the presence of commands like nix-build
reproduce.tt: Use color
Allow a per-jobset check interval

This allows checking a jobset (say) at most once a day.  It's also
possible to disable polling by setting the interval to 0.  This is
useful for jobsets that use push notification or are manually
evaluated.
Restore the links to the contents pages

These were accidentally lost in
80e0e7c84a8798d683960fa57ef8cb3f2456b745.
Fix findBuildDependencyInQueue

Previously this function didn't actually have a lot of effect.  If a
build A had a dependency B, Hydra would start B first.  But on the
next scan through the queue, it would start A anyway, because of the
"busy => 0" restriction.

Now the queue runner won't start a build if a dependency is already
running.  (This is not necessarily optimal, since the build may have
other dependencies that don't correspond to a build in the queue but
could run.  One day we'll start all Hydra builds in parallel...)

Also, for performance, use computeFSClosure instead of "nix-store
-qR".  And don't bother with topological sorting because it didn't
have an effect anyway since the database returns dependencies in
arbitrary order.
Drop unused "disabled" columns
If a build step fail, immediately fail all queued builds that depend on it

This prevents unnecessary work, but it's mostly a refactoring to
support combining notification emails.
Remove Twitter notification support

Turns out Twitter is not an ideal medium for sending build
notifications :-)
Use extra-binary-caches
Add separation between news items
Add a plugin mechanism

You can now add plugins to Hydra by writing a module called
Hydra::Plugin::<whatever> and putting it in Perl's search path.  The
only plugin operation currently supported in buildFinished, called
when hydra-build has finished doing a build.

For instance, a Twitter notification plugin would look like this:

  package Hydra::Plugin::TwitterNotification;

  sub buildFinished {
      my ($self, $db, $config, $build, $dependents) = @_;
      print STDERR "tweeting about build ", $build->id, "\n";
      # send tweet...
  }

  1;
Use "can" to check whether a plugin supports buildFinished
Use OO-style plugins

This is mostly so we don't have to pass around common parameters like
"db" and "config", and we don't have to check for the existence of
methods.

A plugin now looks like this:

  package Hydra::Plugin::TwitterNotification;

  use parent 'Hydra::Plugin';

  sub buildFinished {
      my ($self, $build, $dependents) = @_;
      print STDERR "tweeting about build ", $build->id, "\n";
      # Send tweet...
      # Hydra database is $self->{db}.
  }
Pass failing dependent builds to buildFinished
If multiple dependent builds fail, send a single email
Use Template::Toolkit to generate email messages

Also, make the messages much shorter by not including build details.