Allow custom system-wide defaults to be configured for all component dirs

[timriley]

This PR rounds out the work done in #155, #157, and #158, and makes it possible to configure default values for all component dir settings directly on the container's config.component_dirs. For example:

config.component_dirs.loader = MyCustomLoader
config.component_dirs.default_namespace = "my_app"

# This dir will have the above values applied as defaults
config.component_dirs.add "lib"

This will be particularly useful e.g. for users configuring dry-system to work with an class autoloader like Zeitwerk, which would require the following defaults to be applied:

config.component_dirs.loader = Dry::System::Loader::Autoloading
config.component_dirs.add_to_load_path = false

Having to configure these manually for every added component dir would be a suboptimal configuration experience. Further, the existence of these default settings will make it possible for us to create a plugin to enable a simple use :zeitwerk one-liner in the future.

It should be noted that the order of configuring the defaults and adding component dirs does not matter. The defaults will be applied to added component dirs regardless of whether they have been configured before or after the dirs are added.

Along with this, this PR fleshes out the API documentation for Dry::System::Config::ComponentDirs and Dry::System::Config::ComponentDir.

This introduces one more BREAKING CHANGE for the upcoming release: the top-level loader setting has been removed, with a system-wide loader now possible to configure via component_dirs.loader.

FYI, I plan to squash all commits here when merging.

[timriley]

I had to dig into some dry-system internals here, but it vastly simplifies the logic of apply_defaults_to_dir above.

Previously I was having to inspect the current values for both the system-wide and individual dir settings, the compare them to the setting's own intrinsic default value, and then try and work out from those whether or not to apply the system-wide default. But this would fall down in the case of having a system-wide default that you want to opt out of by explicitly configuring your individual dir to use the intrinsic default value again.

For example:

component_dirs.default_namespace = "my_app"

component_dirs.add do |dir|
  # Explicitly provide nil here, even though it is already the "natural" default for this
  # setting, to opt out of the system-wide default configured above
  dir.default_namespace = nil
end

IMO, this is a reasonable behavior to support (really, I would consider our implementation buggy without supporting this), and without #configured? that I added to ComponentDirs and ComponentDir, it would not be possible to achieve this.

And really, the best case to make for this approach is that #apply_defaults_to_dir is just so easy to read now! if configured?(key) && !dir.configured?(key) – simple!

I'm pretty confident this aspect of dry-configurable will not change, but I wanted to flag it here for you to consider too. If anything, we could consider making a few more parts of it true public API, since this usage here shows that it's valuable.

[solnic]

I had to dig into some dry-system internals here

@timriley you mean dry-configurable internals, right?

[timriley]

@solnic Oops, yes, you're right, I did mean dry-configurable internals :)

[timriley]

@solnic @flash-gordon @jodosha — this is done and ready for review! And with this, the new component_dirs feature is finally done done 😅

[jodosha]

@timriley Nice one! 💯 I assume this would simplify a lot the internals of Hanami 2. 👍

[solnic]

Approved but I've got a couple of minor comments 🙂

[solnic]

I had to dig into some dry-system internals here

@timriley you mean dry-configurable internals, right?