Using a combination of `recompress_response` and `filter_sensitive_data`,
previously VCR would recompress the response first, then try to replace
the sensitive data placeholders with the actual value, however once it's
recompressed, the placeholders can't be found anymore to replace.
Therefore, once your app/library decoded the recompressed response
itself, the placeholders were still there, instead of the expected
values.

This happened because both actions were handled by `before_playback`
hooks. The recompress hook was registered first upon initialization of
the config instance, then the sensitive data hook was registered upon
calling `filter_sensitive_data` (always after initiating the config
instance), leading VCR to run them in order, recompressing then
replacing.

To ensure recompressing always happens last, after all `before_playback`
hooks run, I added a new specific hook, `recompress_response`, that gets
invoked right after invoking the `before_playback` hook. This assumes
you'd never want to run a `before_playback` hook after recompressing.

My usecase is that I'm using the braintree gem, which [requires gzipped
responses][1], however the response has "sensitive" data that I want to
commit with a placeholder since the value might vary across developer
machines, so I use `decode_compressed_response` and
`filter_sensitive_data` so that my committed cassettes use a
placeholder, then combine it with `recompress_response` so the braintree
gem can see the responses as gzipped upon playback, with the
placeholders replaced.

[1]: https://github.com/braintree/braintree_ruby/blob/7d4182b7407bd66061faacadec54960e6c876f72/lib/braintree/http.rb#L174-L180