Reorganise configuration across Rails app and component classes

[boardfish]

This PR aims to rework configuration such that individual component instances can be configured differently, with the end goal of ensuring that applications and engines can define their configuration separately. We're taking a scorched earth approach here, though it will be important to ensure that the migration path from v3 is straightforward.

NOTE: This branch is a WIP – I'll squish things down before it's ready to share.

#1945 sheds some good light on the kinds of problems we're looking to solve here. Big thanks to @Slotos for their really helpful comment on that issue.

[boardfish]

Gave this a day's work while my internet was down. I've gotten to a point where all config lives on Rails.application.config.view_component, which I think is an ideal starting point. From here, I need to:

• review view_component_paths – it looks like we might need two variables, one for the default path for the generator to use and another for the lookup paths for components themselves that we remove from Base#virtual_path.
• move test_controller into component-local config as possibly the only local option so far.
  I've started looking into this, but I'm not sure there's a way to implement what's described here without causing significant friction or getting magical. Right now vc_test_controller doesn't need to know which component it's dealing with – are we okay with that potential?

I think more options need to be component-local, but there are cases like the above where it's not possible without more changes to how ViewComponent is used...

• make sure local config is inheritable – it's behaving unusually. Looks like I'm just duplicating things that ActiveSupport::Configurable already does, but since config is reserved as something that's apparently necessary for forms, we'll probably need to reimplement Configurable under a different endpoint (component_configuration?).
• Make sure configs (ViewComponent::ApplicationConfig and component-local config) call compile_methods! – seems necessary as an optimization to avoid method_missing.

That hopefully gets us to the stage where everything works, but from there I'll need to:

• potentially look at trying this out in a gem with someone who's been affected to understand whether this really does unblock things for gems/engines that depend on ViewComponent
• update the documentation in this PR to lock in the changes, assuming everything's verified to be in the right place
• create a set of RuboCop cops with autocorrect (or a generator?) to ease the migration
• add deprecation warnings to v3

[boardfish]

Chatted about this at maintainer office hours last night, and we came to the conclusion that:

• it should be possible for engines to define configuration local to them – component-level config shouldn't be the only option, because things like test_controller shouldn't sit so close to app code.
• we should start by making backwards-compatible changes that we can merge into v3 to make the migration path to v4 easier, rather than starting from v4 and working back
• once we have a pattern for engine-local and component-local options, we can share the work of moving all config options to their intended new locations.

[boardfish]

Closing in favour of #2230 and #2231, but I'll be doing other things mentioned in here as followups (e.g. easing the migration with a codemod/cop).