Add ExpressibleByConfigStringArray support for string array–convertible types

[woolnd]

Related to #138

Motivation

Some configuration values are naturally represented as arrays of strings, but should be interpreted as a single domain type.
A common example is HTTP headers:

{
  "headers": ["X-Foo: Bar", "X-Baz: Qux"]
}

Currently, ExpressibleByConfigString only supports single string values, which makes it impossible for types like HTTPHeaders to conform to it.

This PR introduces a new protocol, ExpressibleByConfigStringArray, to support types that require multiple strings for initialization while preserving the existing ConfigReader API patterns.

Modifications

This PR introduces:

1. A new protocol:

public protocol ExpressibleByConfigStringArray: CustomStringConvertible {
    init?(configStringArray: [String])
}

2. New ConfigReader APIs for string-array-convertible types, following existing patterns:

• Get (sync)
• Fetch (async)
• Watch (AsyncSequence)

Each access pattern includes:

• Optional
• Default
• Required variants

In total, 9 new APIs were added for ExpressibleByConfigStringArray.

3. Test coverage for all new APIs:

• ConfigReaderMethodTestsGet4
• ConfigReaderMethodTestsFetch4
• ConfigReaderMethodTestsWatch4

The tests cover:

• Successful conversions
• Missing values
• Provider failures
• Default fallbacks
• Required-value error handling

No existing APIs were modified.

Note on generated sources

While regenerating the generated sources, I ran into formatting-only diffs (indentation/whitespace) that made the branch noisy.
To keep the PR focused, I reset my branch to the pre-regeneration state and reapplied only the functional changes for this feature.

Result

After this change, configuration values defined as arrays of strings can be directly converted into domain types (example key: "headers"):

let headers = config.stringArray(forKey: "headers", as: HTTPHeaders.self)

This enables cleaner configuration modeling for types like HTTP headers, while keeping the API consistent and backward-compatible.

Test Plan

• Regenerated sources and verified the generated output
• Ran the full test suite locally:

swift test

All tests pass successfully.

Notes

This is my first contribution to SwiftConfiguration.
I’d really appreciate any feedback on the API design or naming choices.

[woolnd]

@czechboy0
Update: converted this PR to Draft as requested and force-pushed a cleaned-up history to keep the diff minimal.
Regenerated sources for validation and reverted formatting-only diffs; swift test passes locally.
I’d appreciate feedback on the API shape/naming before marking it ready for review.