build: reorganize #install for readability
ENV.with_build_environment
Allow env DSL to take a block

In addition to

  env :userpaths
  env :std

formulae and requirements can now do

  env do
    append 'PATH', '/some/path/to/bin'
    # and more
  end
Temporarily export requirement ivars to ENV

We want to evaluate the env DSL block in the context of ENV for asthetic
reasons, but we also want to evaluate it in the context of the instance
of the defining requirement, so that we can use its instance variables
to, for instance, add a path discovered in `satisfied` to PATH. Observe:

  env do
    append 'PATH', @path_to_some_binary
  end

  satisfied do
    # some code that sets @path_to_some_binary
  end

To faciliate this, temporarily copy the instance variables from the
calling requirement into ENV. Once the env block has been evaluated,
remove the instance variables to prevent so as not to contaminate it any
further.
Block-style env DSL examples
Allow satisfied? to be specified in a block

Instead of overriding #satisfied?, Requirement subclasses can specify
the condition in a block:

  satisfied do
    some_condition?
  end

The contents of the block are evaluated in the context of the instance,
and so have access to instance variables and instance methods as before.
Additionally, it is wrapped in an ENV.with_build_environment block. This
can be disabled by passing :env => false to satisfied:

  satisfied :env => false do
    some_condition?
  end
tests: add mocha mocking library
env :userpaths applies to satisfied block

When requirements specify 'env :userpaths', it is now applied to the
evaluation of the block passed to satisfied as well as the build of the
dependent formula.

It can also be specified in the options hash passed to satisfied:

  satisfied :userpaths => true do
    # ...
  end

this is useful when we need userpaths temporarily in order to locate a
binary, but we don't want to inject _all_ of userpaths into the build.