Refactored builder a bit

- Stored the model (or model copy) on the builder so that
  it doesn't have to be passed to every function
- Used append instead of += [...] to avoid making new lists
  for each new op (timeit claims it's about twice as fast,
  though we're talking about tiny numbers so the speed
  probably doesn't matter that much)
Removed ConstantNode, Node output can be constant

- This was originally done because the two situations
  were much more different, but with more recent code
  there's a lot more overlap
Signal/NonlinearityConnection -> Connection

- The two did essentially the same thing now.
  They had somewhat different behavior when signals were
  exposed at the high level, but they aren't anymore.
Implemented Direct mode

The way we were thinking about direct mode previously doesn't match the
semantics of Nengo 1.4. Basically, we were treating direct mode
ensembles like nodes, which is incorrect.

A node takes input and computes one function, providing the results of
that function as outputs. Connections from nodes cannot compute
functions. Direct mode ensembles, on the other hand, do not actually
compute anything, they just perfectly represent their input. Connections
from direct mode ensembles can have functions, and they should be
directly computed rather than approximated with decoders.

I implemented a new Direct class that implements the same interface as
other Neurons classes do. I rearranged the nonlinearities module quite a
bit so that this makes sense. In the build process, decoded connections
have a bit of custom code to skip build decoders, and instead compute
the function directly.

What was previously the Direct class (which was mainly used for Nodes)
has been renamed to PythonFunction, which is a bit more descriptive as
to what this nonlinearity actually does. Nodes now build a
PythonFunction in the build step. Decoded connections from direct mode
ensembles also build a PythonFunction in the build step.

Unlike Nengo 1.4, Direct mode ensembles and connections to and from them
still respect the filters that are applied to them. Therefore, the
output of a direct mode ensemble is not precisely the same as its
input (as is the case in Nengo 1.4), and when filters are applied there
are startup transients and all that kind of stuff.
Removed transpose from DotInc (use signal.T instead)
Fixed test_signal_init_values to work with nengo_ocl
Some builder refactoring

- Everything has an input_signal and output_signal, if appropriate,
  which makes connection code much easier
- Modulatory connections work now; they create a new signal rather
  than DotInc-ing to post.input_signal, so other things
  (i.e., learning rules) can use them.
assert_allclose tolerance based on dtype