Brick inputs and outputs are tagged with an application call

The application call can be used to e.g. include auxiliary variables, such as monitors, extra cost terms etc.

Also: fixes to graph parsing.
Just wondering if you have given any more thought to the semantics of adding monitoring channels: The variables need a bit more information to be able to be interpreted as a monitoring channel e.g. do they need data, and if so, what operator should be used for the reduction (i.e. do we want the mean, max, etc. over batches). I guess we should add that information as tags, and then search the `ComputationGraph` later in order to convert them into `MonitorChannel` instances (see my monitor_and_train branch), because we don't want the `Brick` class to rely directly on the `MonitorChannel` interface.

I guess an interface like this would be nice:

```python
def apply(inputs):
    ...
    return outputs

@apply.monitor_channels
def apply_monitor_channels(self, inputs, outputs):
    rvals = {}
    rvals['mean_weights'] = create_monitor_variable(self.W.mean(), needs_data=False)
    rvals['shannon_entropy'] = create_monitor_variable(-tensor.sum(outputs * tensor.log(outputs)), needs_data=True, reduce=np.mean)
    return rvals
```
But it raises the question as to how we add monitor channels that rely on targets, but maybe those shouldn't be given by bricks in the first place?