filter_chain: separate keys filters and execute them last

[kyrylo]

Fixes #158 (blacklist_keys does not remove sensitive information from
post bodies)

This ensures that blacklist/whitelist filters always execute last.
Without this change blacklist/whitelist filtering is broken in
airbrake v5.7.0.

Since 8b8af2c77ea42b70b949e3b85df6cce3c977ee40 in airbrake/airbrake
Rack filters are being added after blacklist/whitelist filters, which
means Rack requests are never filtered.

In general, this change makes sure we blacklist/whitelist after all
permutations on a notice are done.

[vmihailenco]

This depends on knowing list of filters that should be run in specific order. What about adding optional priority field to the filter class that has 0 default value and then sort filters by priority field (preserving original order - see https://en.wikipedia.org/wiki/Category:Stable_sorts)? Then Airbrake::Filters::KeysBlacklist should have priority = -1.

Another option would be to split filters into builders and filters. And make sure builders are run before filters. I like this less because it requires users to know the difference between builders and filters.

[kyrylo]

What about adding optional priority field

Do we really need this flexibility? I don't see the real need for this, but it definitely sounds cool. I feel like what's done here is simple and understandable. Probably not as elegant as the priority approach, but it does the job with minimum code. I can keep the priority approach in mind in case the current way of filtering causes problems.

Another option would be to split filters into builders and filters

Not a big fan of this because I'm not sure how to allow the user populate builders. We got rid of rack builders in the previous release, so I think airbrake-ruby shouldn't even know about this word in this repo.

[vmihailenco]

I'm not sure how to allow the user populate builders

add_builder?

[kyrylo]

This will look a bit strange in the light of our Airbrake.add_rack_builder removal :)
Besides, the name is not good enough because users likely won't be able to figure out what this does without reading docs.

[vmihailenco]

Yes, that why I suggested priority field first.