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.
Welcome back to Europe.

This PR was only for a more structured way of extracting auxiliary information out of the graph. 
Stuff that you want extracted may be:
- monitors
- auxiliary costs

The aggregating monitors will be in an extension. I like the idea of writing err_rate=fraction(num_errs, num_examples_in_batch) and knowing that during monitoring it will report the value truthfully even when batch_size varies from batch-to-batch. Mean over batches of the per-batch means de-emphasizes examples in large batches.

Now to be able to do it by acting on a list of minibatch results I have to:
- either return a binary matrix indicating correct samples, concatenate it over batches and take the mean. This can work, you are just moving more memory around.
- return two intermediate numbers, num_errs and num_examples, then sum then in the aggregation. My idea is to hide the two numbers in the aggregator.