StoreAPI::buildPaths: Report replaced drvs to the caller.

Also handle replacements properly at all buildPaths call sites.
build.cc: Misc bug fixes

1. Use ? instead of ! as the recursive input signifier to avoid clashing
   with the ! in string contexts
2. Remove the .drv suffix from the current drvPath when passing its name
   to writeDerivation for the rewritten drv
3. Rather than calling worker.run in a loop (which doesn't actually
   work), insert the replacement of ecReplaced topGoals into topGoals.
Properly handle replacements in realisePath when not building
Add a recursive derivation concept to the nix language

When a derivation can't be reasonably instantiated at evaluation time
(e.g. because it requires downloading a source tarball and evaluating a
nix expression contained within), you can use a recursive derivation
that *can* instantiate it at build time as a stand-in at evaluation
time. When any derivation that depends on a recursive derivation is
built, nix will fix up the input at build time so that everything is as
if the derivation had been instantiated at eval time.

To create a recursive derivation, follow these rules for the arguments
to the derivation primop:

* __recursive = true
* name is the same as the name for the build-time instantiated drv
* outputs is the same as the set of outputs for the build-time
  instantiated drv
* During the build of the build of the derivation, regardless of the
  setting of outputs the only valid output will be $out
* The build should make $out a symlink to the derivation that this
  recursive derivation will be replaced with.

The result of that derivation call can then be passed around the nix
language as normal, though it should be noted that the drvPath attribute
is not replaced at build time. If this is a bit hard to follow, see
tests/recursive-derivation.nix and note that when built, the output path
of usesUsesRecursive is the same as the output path of usesUsesDirect
(as verified in the test case).

The use case for this is as follows: Suppose nix has finally taken its
rightful place as the best build tool out there, and x.org decides to
replace their entire build system with nix. Being good developers, they
want to reuse library functions and packages already defined in nixpkgs,
and while the packages could theoretically be passed as environment
variables the library functions (such as stdenv.mkDerivation) as well as
any passthru attributes will only be available from the nixpkgs nix
expressions. This poses a problem, even with recursive nix: Every time
nixpkgs changes (even a whitespace change), x.org will have to be
rebuilt. Of course the rebuild of x.org itself will be very fast, as its
recursive nix call will already be built (unless a dependency actually
did change), but nevertheless every package that depends on x.org will
need to be rebuilt! This is where recursive derivations step in: The
x.org expressions in nixpkgs make recursive derivations that download
the tarball, instantiate the build expressions, and symlink the desired
derivation to $out. Then any time nixpkgs changes, this symlink will
have to be rebuilt (which will be fast), but then the rewrite will kick
in and dependent packages will end up unchanged and thus not need a
rebuild.