Fix setup.py not installing NumPy

It seems to install just fine if NumPy is in `setup_requires`
rather than `install_requires`. I'm not sure if NumPy should be
removed from `install_requires`, but I feel like best not to touch
it in case something reads `install_requires` but not `setup_requires`.

Tested on Mac OS X 10.10 and setuptools 2.2. Doesn't install NumPy
twice, but leaves an annoying `.egg` folder in the Nengo directory
(which can be removed with no ill-effects).
Added dists and utils to Nengo namespace

As per the will of #548.

- Moved nengo/utils/distributions.py -> nengo/dists.py, which
  required a bunch of changes in import statements
- Imported things in nengo/utils/__init__.py, and imported utils
  in nengo/__init__.py, which should remove the need for some
  import statements in model code
  - This necessitated changing some imports in utils from absolute
    to relative. Not sure if this is an improvement...
Removed magic from Network.

Specifically, removed the NengoObjectContainer metaclass, and the
Network.__new__ function. This means that all Network subclasses
need to explicitly take in and deal with `label`, `seed`, and
`add_to_container`, and have to explicitly do `with self:`
if they make any Nengo objects. These changes end up being
alright for normal networks, but a little cumbersome
for SPA networks.

A few other minor changes:
- Made Network.add a staticmethod instead of a classmethod.
  The class being used should always be Network, I think.
- Now using the `Choice` distribution in `SPA.Compare`
  (missed it when converting the others...)
- Switched all of the SPA tests from subclassing to
  using a context manager.
Minor config system tweaks

- `Config.__init__` now accepts the classes to be configured.
  We use this `Network.default_config` and several tests.
- `InstanceParams` falls back to `ClassParams` instead of
  `param.default`. Includes test for this.
- Implemented some `__contains__` methods for easier checking
  of whether a certain parameter is configured, and where.
Converted network subclasses to functions

In general, I think that the resulting functions are easier to read
than their networks subclass equivalents.

Of note is the pattern of accepting a premade network, or
making a new one if none is passed. This has a few concrete benefits.
One is that the BG / Thalamus doesn't need to accept label, seed,
and add_to_container arguments because if you want something other
than the default, you just quickly make a network with those values
and pass it in (this is done in `test_actionselection.py`).
Similarly, if you want to change something like the max firing rates,
you can make a new network, change the max firing rates in that
network's config, and it will just use them.

Other changes:
- Added the `nested` function to `nengo.utils.compat`. This is the
  only way we can do nested context managers in a way that works
  on Python 2.6 and above; if we don't support Python 2.6 then we
  don't have to include this function.