disallow some configuration & transformer chaining

[boneskull]

Normally I wouldn't go for this, as I like to give the user a lot of control, but I think we're doing way too much work to support every potential use-case.

To that end, I want to remove some configuration. Transformers, I think, are way too convoluted and try to do too many things.

So:

1. Remove the ability to use multiple transformers in sequence
2. The only one that's really useful with others is filter, so filtering should become an option to all transformers, where applicable.
3. Reconfigure "input" filter in diff command to compare everything, then rely on output filters (defined in previous item) to remove cruft by default
4. Remove input filters
5. Each command will have some configuration over how it works with each transform that it works with. I recommend a "default" transformer config--where appropriate (like fields; see json transformer should use field labels #39) and overrides on a per-transform basis
6. Only a subset of transformer configuration should be configurable by the user. fields should not be; most of the table configuration should not be. Each configuration option will need to be evaluated on a case-by-case basis.

I envision looking more closely at this when I get to documenting configuration (#66). But if someone wants to take a crack at it, I can make myself available to help.

[boneskull]

what's needed here, I think, is essentially a flowchart or outline of how configuration should work. it needs to answer these questions:

1. what is configurable?
2. for each configurable subsystem, where does its configuration live?
3. for each configurable item in each configurable subsystem, what actors can configure it? other subsystems, users, etc.
4. for each configurable subsystem, illustrate the configuration precedence: if two actors configure a subsystem, which actor is preferred?