Faster full convolution for GpuCorrMM

As a follow-up to #2023, this PR adds [caffe's backward pass wrt. inputs](https://github.com/BVLC/caffe/blob/master/src/caffe/layers/conv_layer.cu#L98) to GpuCorrMM to implement `border_mode="full"`. It passes all the tests and it's about 2-4x faster than simulating a full convolution with a padded valid convolution. On the way, it cleans up the code and adds some more elaborate documentation.

There are some caveats, though, all stemming from the fact that the implementation in caffe is meant as a backward pass for a valid correlation:
* With `border_mode="valid"`, `GpuCorrMM` doesn't flip the kernels, but with `border_mode="full"`, it does.
* With `border_mode="valid"`, `subsampling` is for subsampling the output, but with `border_mode="full"`, it is for upsampling the input.
* With `border_mode="valid"`, `pad` is for padding the input, but with `border_mode="full"`, it is for cropping the output.
* With `border_mode="full"`, it needs a different memory layout for the kernels.

Currently, `GpuCorrMM` directly wraps the underlying algorithm, and `local_conv_gemm()` copes with the different peculiarities, because I wasn't sure whether the `GpuCorrMM` Op should be inserting dimshuffles, kernel flips and `gpu_contiguous`es on its own.

Looking at the end result, although it's quite fast, `local_conv_gemm()` now basically undoes everything that `ConvOp.grad()` does. It might be possible to write an optimizer that replaces the gradient of a valid convolution with a properly parameterized `GpuCorrMM` Op, instead of just replacing the full convolution Op that is part of the gradient (introducing redundant dimshuffles etc. on the way). This way we would leverage the caffe implementation better.
The alternative would be to modify the CUDA code to perform a subsampled, padded, full correlation, as would be expected from a Gpu Correlation Op. This would be cleaner, but it would also mean a lot more work and we wouldn't profit as much from caffe's implementation for the case of `subsampling != (1,1)` or `padding != (0,0)` (granted, this may be an uninteresting case in practice anyway).
/edit: Another alternative would be splitting this into two Ops: `GpuCorrMM` for valid correlation with padding and subsampling (the caffe forward pass), and `GpuConvMM` for full convolution with upsampling and cropping (the caffe backward pass). This way it would be obvious how the operations differ, but the memory layout required for the second Op would still be unintuitive.
Yet another alternative would be splitting it into `GpuCorrMM` and `GpuCorrMM_gradInput`. This way it would be obvious how to use `GpuCorrMM_gradInput` for computing the gradient of `GpuCorrMM`. We could even add `GpuCorrMM_gradKernel` for the gradient wrt. weights; it seems caffe does things slightly different there as well.
In both cases, `GpuCorrMM` should get a `grad()` method to define its gradient (so it can be used directly in a CNN to avoid kernel flipping and whatnot) and `local_conv_gemm()` should still be able to replace any `GpuConv` instances with a gemm-based Op (so it can be used with existing CNN implementations).
I think the batch size will also play a role, because in one case (fprop), the gemm is used to accumulate over the channels and the for loop to iterate over the minibatch, and in the other case (bprop weights), the for loop is used to accumulate over the channels (= minibatch of the forward pass) and gemm to iterate over the minibatch (= input channels of the forward pass).

I had a benchmark of the two implementations running over night, I will try to figure out a formula to choose between them. A nice aspect is that this may allow us to be faster than caffe/Torch for certain configurations, because in caffe/Torch it's hard-coded which implementation to use in the forward and backward pass.

The problem I see with joining both implementations into one Op is that they require very different memory layouts for the input and output. To compare, these three perform the same computation (copied from `test_gemm_directly()`):
```python
cpuval = py_conv(npy_img, npy_kern, 'valid', subsample)

op = theano.sandbox.cuda.blas.GpuCorrMM(border_mode='valid',
        subsample=subsample)(i, k)
f = theano.function([i, k], op, mode=theano_mode)
gpuval1 = f(npy_img, npy_kern[:,:,::-1,::-1])

op = theano.sandbox.cuda.blas.GpuCorrMM_gradWeights(border_mode='valid',
        subsample=subsample)(i, k)
f = theano.function([i, k], op, mode=theano_mode)
gpuval2 = numpy.array(f(npy_img.transpose(1, 0, 2, 3),
        npy_kern.transpose(1, 0, 2, 3)[:,:,::-1,::-1])).transpose(1, 0, 2, 3)

# cpuval, gpuval1 and gpuval2 are now approximately equal
```
If we do the necessary dimshuffles, kernel flippings and gpu_contiguous calls inside the C code of a merged Op, we will probably do unneeded copies. If we do them in Python, we might still do unneeded copies unless we create an optimizer that can merge chains of dimshuffles with gpu_contiguous calls in between. Besides, keeping the code similar to caffe makes it easier to port upstream changes to Theano in case there are any.

So I'd prefer to keep the Ops separate for now, and leave merging them for another PR if that's okay with you.