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.
Sorry for the slow responses; I'm in the Netherlands now and have been busy with a lot of social obligations after not having seen people for a year.

I'm not convinced by the need for these complicated aggregation schemes. For very complicated cases one could simply write a monitor channel consisting of a function. I don't think we should build support in for these complicated cases directly, considering how relatively uncommon they are, but how complicated they make the framework.

This sounds like exactly something Dima would accuse me of, but I think we shouldn't try to make things *too* general, because we lose the simplicity and clarity of the framework. I think that some rarer cases, even though valid use cases, should be implemented using extensions, or in this case, callbacks, instead of cluttering the entire framework.

I am aware that expecting to write the user to write a callable function means that the computational efficiency could be sub-optimal (because the Theano computations can't be compiled together), but maybe this is worth it for the sake of simplicity.

I feel that in many cases, you can also solve this by some clever reshaping. If you want to calculate per-word statistics, you simply collapse the first and second axes so that you can take the average over that:
```python
output_words = output.reshape(output.shape[0] * output.shape[1], output.shape[2])
[mask.flatten().nonzero()]  # Averaging over the first axis will give you per word statistics
```