Migrate strip_trailing_whitespace to use component-local config under the hood

[boardfish]

• Introduce component-local config
• Migrate strip_trailing_whitespace to component-local-config
• Update changelog

What are you trying to accomplish?

Following an initial exploration of this in #2210, I agreed with @joelhawksley and @camertron that we should take an incremental approach and roll out component- and engine-local config in V3, making deprecations that would be effective come v4. Our end goal here is to make it more practical to include view_component as a dependency in engines and gems, which are currently subject to the same config as the parent app they're included into.

trim_trailing_whitespace seemed to be an ideal candidate for being part of a component-local config entity, since (being an instance variable already) it effectively works in the same way.

What approach did you choose and why?

The ComponentLocalConfig module essentially replicates ActiveSupport::Configurable, but puts the config on configuration as opposed to config, which appears to point to Rails.application.config as-is. This could be changed down the line, but since I wasn't sure of what that config alias was used for right now, I essentially aliased the functionality. That having been said, we could always change this later if it turns out that it's not something that will cause much trouble - these two method names being similar could potentially be an issue when component-local config is more public.

Anything you want to highlight for special attention from reviewers?

Because the component local config module essentially aliases functionality we'd otherwise get from ActiveSupport::Configurable, it might be safe for us not to test it directly. It's minimally tested for inheritability in this PR. I had to mark a couple of methods as nocov since I'm almost certain that they're exercised during init, but Simplecov didn't appear to pick them up.

[joelhawksley]

This looks good. What docs updates do you think we should make?

[boardfish]

I was thinking we should have docs for the new config ready against v4 instead, but now that I think about it, it'd make sense to at least reflect the deprecation in the current docs. I'll do that next and accept that tweak to the changelog message.

[joelhawksley]

Looks good to me! Some minor notes.