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.
Hi, I want to separate two concepts which are orthogonal to each other:
1. a way to return auxiliary variables from a brick.apply call through the list of application_call.auxiliary_variables.
2. an aggregation scheme tag, which can be used on auxiliary as well as regular outputs too to know how to aggregate them (e.g. final cost is a regular output, the aggregation scheme tells us how to automatically correctly compute it on a validation set).

Ad.1: The application_call.auxiliary_variables holds auxiliary things computed by the brick. These can be monitors, additional costs, or e.g. asserts. Thus not all of them need to have an aggregation (reduction) scheme. The auxiliary variables have a suitable role tag which tells their use, I am open for suggestions  which roles do we want. The role tags would be used e.g. to select them.

Ad 2:
I tentatively started to refer to averaging_method as aggregation. Reduction is fine too. maybe even MinibatchReduction or MinibatchAggregation? This make it even more explicit.

The user will not attach the tags himself. Here is my idea (my take on what we discussed with Dima):

The aggregation scheme tag is more than just a numpy reduction. Consider the average bits-per-word in the whole set. It is not the same as average over batches of average over words. Proper computation over a full data set requires keeping track of two values: the number of bits, and the number of words. I propose to:

1. define an aggregation scheme class with three methods:
- allocation of shared var accumulators + listing of theano updates that initialize them. The initial values must not depend on the data.
- listing of theano updates to run over each aggregated batch of data
- a finalization method that computes the final value using the accumulators.
2. define a convenience functions, such as aggregated_fraction(numerator, denominator) that return an expression with a proper aggregation_scheme tag.

This scheme obviates the need for flagging whether we need data or not. Monitors of parameter properties, such as column norm would simply compute the value in the initialization update, then do nothing during the loop over the data.

The scheme is very general, and it should be easy to e.g. compute micro- and macro- averaged class losses http://datamin.ubbcluj.ro/wiki/index.php/Evaluation_methods_in_text_categorization etc.