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.
I'm aware this PR didn't decide on any interface; just figured I'd continue the discussion here. I have no issues with the principle, but mostly with the interface, which I want to make sure stays simple for the basic cases of monitoring values that don't require data, or which are simply average over examples (which covers 99% of use cases). For these cases, I don't think you should need to provide an entire averaging scheme (`fraction(num_errs, num_examples_in_batch) `). This flexibility should be reserved for the exceptional cases where we average over elements (words) in temporal sequences (sentences), or for when for some reason we want to average over batches of non-fixed size.

Otherwise, no problem with this PR, I like the design choice. There are a few tiny documentation issues, but I'll fix those when I have the time (no newline after the opening `"""`, and the summary description after `"""` cannot exceed 1 line).

Also, I think comments should only be used to explain non-obvious programming logic, and I guess we can use them to tag `# TODO`. I'd prefer that we do not merge questions or personal opinions as with this PR. Those will just linger and confuse people 1 year from now.