Python layer for rapidly writing nets in Python

~~This PR depends on #1014, and shouldn't be merged before that one.~~

Caffe is fast, but adding new layers is a multistep process (see #684), and is subject to all of the pitfalls of development in a low-level, compiled language. For quickly trying new ideas, speed of development may be more important than runtime speed.

This PR addresses this gap by allowing layers to be written in Python. One adds layers to the net prototxt that look like the following:
```
layers {
  name: "python"
  type: PYTHON
  bottom: "data"
  top: "output"
  python_param {
    module: "my_module"
    layer: "MyLayer"
  }
}
```

Then, one implements layers in Python with more or less the same interface as in C++, as below.
```python
class MyLayer(object):
    """Simple layer that multiplies input by ten."""

    def setup(self, bottom, top):
        pass

    def reshape(self, bottom, top):
        top[0].reshape(bottom[0].num, bottom[0].channels,
                bottom[0].height, bottom[0].width)

    def forward(self, bottom, top):
        top[0].data[...] = 10 * bottom[0].data

    def backward(self, top, propagate_down, bottom):
        if propagate_down[0]:
            bottom[0].diff[...] = 10 * top[0].diff
```

In order to make this work, the main caffe binaries need to be linked against the Python libraries. This is solved by adding a build option, `WITH_PYTHON_LAYER`, as well as a couple `ifdef`s. These changes are probably not quite ready for merge; in particular, this should break the cmake build system, and the build option is not being tested in Travis yet. (@akosiorek or others, if you're eager to make this work with cmake, PRs against this branch are welcome.)

Layers with learnable parameters are not supported yet.

In theory, this means you ought to be able to write layers in Theano (making use of Theano's symbolic differentiation), embed them in caffe nets, and solve using caffe. I haven't tried that yet, but it might be worth adding some Python-level helper code for that later on.

This hasn't really been tested at all (but does build and run).

[Compilation] I think this causes the mutliple definition problem: python/caffe/_caffe.o is going to be linked into libcaffe.a because of this, and then when we make pycaffe, python/caffe/_caffe.cpp (which _caffe.o comes from) gets linked again - causing multiple definitions.

We should remove this line (together with other changes, see below).