Add explicit config inheritance with `includes` field

This enhancement request proposes adding explicit config inheritance through an includes field, allowing configuration files to explicitly declare which other configuration files they want to inherit from and in what order.

Context

Currently, JP supports implicit inheritance through the directory hierarchy (inherit field controls whether parent configs are loaded). However, there's no way to explicitly include specific configuration files by name or path. This limits the ability to create reusable configuration modules that can be composed together.

The proposed includes field would allow creating modular configuration files that can be explicitly combined, similar to how many other configuration systems work (webpack, eslint, etc.).

Alternatives

Alternative approaches considered:

1. Single includes array: Could use a single array with explicit ordering, but before/after semantics are clearer about merge precedence.

2. Extend existing inherit field: Could make inherit accept more complex values, but this would complicate the existing boolean logic.

3. CLI-only inclusion: Could rely only on --cfg flags, but this doesn't allow for persistent, declarative composition in config files.

Proposed Implementation

Add a new includes field to the configuration schema with two sub-fields:

[includes]
before = [
    { path = "model/sonnet" },
    { path = "persona/rust-developer" },
]
after = [
    { path = "shared/defaults" },
]

The before array specifies files to be loaded before the current config (current config merges on top), while after specifies files to be loaded after (they merge on top of current config).

Files are resolved using the existing config_load_paths mechanism, supporting the same fuzzy matching for file extensions (.toml, .json, .yaml, .yml).

Tasks

Add includes field to Config struct with before and after arrays

• Implement includes resolution in load_partial_from_file using existing find_file_in_path logic
• Add cycle detection to prevent infinite recursion when includes reference each other
• Add configuration field assignment support for includes in AssignKeyValue trait
• Add comprehensive tests covering include resolution, ordering, and error cases
• Update documentation to describe the new includes feature
• Consider interaction with existing inherit field - whether includes should be processed before or after hierarchy inheritance

Resources

https://github.com/dcdpr/jp/blob/main/crates/jp_config/src/config.rs#L22-L127
https://github.com/dcdpr/jp/blob/main/crates/jp_config/src/parse.rs#L21-L54
https://github.com/dcdpr/jp/blob/main/docs/configuration.md#L112-L128

Start with crates/jp_config/src/config.rs and crates/jp_config/src/parse.rs, then read the configuration documentation at docs/configuration.md. Define how before and after includes interact with hierarchy inheritance, implement resolution and cycle handling, and add tests and documentation covering ordering, errors, field assignment, and the completed feature.