Decode filters

[rijnhard]

Hi

I added the ability to specify decoding filters.
and provided a zendBoolean normalizer as a predefined filter.

It's still a pretty naive implementation in that only manipulates values.
Ideally it should be able to remove whole keys, but I would say that is additional functionality.

The reason for wanting to use filters is that it provides a nice simple way of guaranteeing that values meet an expected criteria after parsing. And it removes the need for complex object navigation in order to do it after the fact.

[rijnhard]

@isaacs can we kick off a discussion on this?

1. Do you like the concept of allowing parsing filters?
2. (assuming yes) what would the requirements be to make this merge ready.
3. (assuming changes) Lets talk design and criteria:
   1. do you want to allow key based filters (how to handle sections, and key matching...)

I also added the zendBoolean here for an illustration, but we either add more defaults, or I can separate them into standalone packages

[rijnhard]

On and forgot - another topic, encode filters.

[rijnhard]

I've been thinking how to make this more flexible.
Namely to handle keys and some pretty specific parsing logic that some other issues relate to like semi colons in string literals.
It does mean that the filters need to be used sooner in the parsing logic, and that a lot of predefined logic can be moved to filters.

the nasty parts are defining default filters if specific filters weren't defined, it makes me think a flagging system is better but that would limit the use of custom filters. I haven't yet thought of a decent way to make the function call simple and allow custom filters.

[rijnhard]

Forking the project instead, since no feedback