Modularize superenv

This is an attempt to eliminate side effects related to loading superenv.

Currently, the methods that comprise superenv are defined directly on the singleton class of ENV. This is problematic, because it means the changes made by loading superenv.rb are "permanent" and cannot be overridden.

To illustrate, consider the following (using Ruby 2.1 so that the singleton class is visible in the list of ancestors, but the effect is the same across all Ruby versions):

```rb
class << ENV
  def setup_build_environment
    p "superenv!"
  end
end

module Stdenv
  def setup_build_environment
    p "stdenv!"
  end
end

p ENV.singleton_class.ancestors
ENV.setup_build_environment
ENV.extend(Stdenv)
p ENV.singleton_class.ancestors
ENV.setup_build_environment
```

This produces:

```
[#<Class:#<Object:0x872b98>>, Enumerable, Object, Kernel, BasicObject]
"superenv!"
[#<Class:#<Object:0x872b98>>, Stdenv, Enumerable, Object, Kernel, BasicObject]
"superenv!"
```

This is not what we wanted to happen; simply by loading superenv.rb without first pushing `--env=std` onto ARGV, we have made it impossible to use stdenv.

A similar thing happens in the other direction: if we load superenv.rb *with* `--env=std` in ARGV, we cannot switch to superenv, because superenv method definitions are guarded by `if superenv?`.

So we need to modularize the superenv code, make it possible to use independent of the actual build environment, and delay any actual mutation of `ENV` until just before we kick off the build.