Command plugin should skip irrelevant targets when run without --targ…
…et argument (#798)
### Motivation
In #795 we adjusted the logic of the command plugin because errors were
not propagating properly. As a result, we regressed behaviour when the
command plugin was run without any `--target` argument. In this mode,
the plugin runs on all targets. When it detects a misconfigured target
it errors, as it should. However, the classification of misconfigured
target included targets that were not intended for code generation at
all, resulting in errors running the command plugin on packages with
others targets.
### Modifications
- Add command plugin generation step to integration test
- If the command plugin is running without a `--target` argument and
cannot find _any_ of the required files, skip that target.
### Result
- Manual code generation with the command plugin fixed for packages with
other targets.
- Fixes #797.
### Test Plan
This PR includes two commits. The first adds a step to the integration
test, which runs the command plugin on the integration test package.
This will fail in CI. Then the second commit will provide the fix, which
should pass in CI. The commits will then be squash merged.

Fix final layer of error handling in command plugin (#795)

Add type overrides key to the docs (#788)
### Motivation
In #774 and #764 we missed adding the docs for the new key in the config
file.
### Modifications
Added the missing docs.
### Result
Type overrides property documented.
### Test Plan
N/A

Add support for configurable comments in generated files (#773)
### Motivation
Users want the ability to add custom comments to generated files. One
concrete use case is adding directives like `swift-format-ignore-file`
and `swiftlint:disable all` to prevent these tools from processing
generated code.
### Modifications
- Added `additionalFileComments` property to `Config` and `UserConfig`
structs
- Modified `FileTranslator` to include additional comments along with
the do-not-edit comment
- Added CLI support with `--additional-file-comment` option
- Added config tests to confirm the option propagates and the default is
empty
- Added snippet tests to validate the actual rendering
- Updated documentation with examples and usage instructions
### Result
Users can now configure additional comments to be added to generated
files using either the config file or a command line option.
Fixes #738.
### Test plan
- Added unit tests for `Config`
- Added snippet tests for rendering
- Manual tests of generator using config and CLI on real OpenAPI doc:
```console
% swift run swift-openapi-generator generate openapi-documents/petstore.yaml \
  --mode types \
  --output-directory test-output-cli \
  --additional-file-comment "hello world" \
  --additional-file-comment "testing, testing, 1, 2, 3"
Build of product 'swift-openapi-generator' complete! (3.27s)
Swift OpenAPI Generator is running with the following configuration:
- OpenAPI document path: /Users/Si/work/code/swift-openapi-workspace/packages/swift-openapi-generator/openapi-documents/petstore.yaml
- Configuration path: <none>
- Generator modes: types
- Access modifier: internal
- Naming strategy: defensive
- Name overrides: <none>
- Feature flags: <none>
- Output file names: Types.swift
- Output directory: /Users/Si/work/code/swift-openapi-workspace/packages/swift-openapi-generator/test-output-cli
- Diagnostics output path: <none - logs to stderr>
- Current directory: /Users/Si/work/code/swift-openapi-workspace/packages/swift-openapi-generator
- Plugin source: <none>
- Is dry run: false
- Additional imports: <none>
- Additional file comments: hello world, testing, testing, 1, 2, 3
Writing data to file Types.swift...
% head -5 test-output-cli/Types.swift
// Generated by swift-openapi-generator, do not modify.
// hello world
// testing, testing, 1, 2, 3
@_spi(Generated) import OpenAPIRuntime
```

Add support for Windows (#753)

Only apply standard swift settings on valid targets (#742)
Only apply standard swift settings on valid targets. The current check
ignores plugins but that is not comprehensive enough.

[Cleanup] Make Config's namingStrategy and accessModifier params cons…
…istent (#713)
### Motivation
A missed fixup from #708:
#708 (comment)
### Modifications
Removed the default from Config.init and forced all callers to make a
choice on the naming strategy, just like for accessModifier.
### Result
Consistent handling of these two parameters.
### Test Plan
Tests passed locally.

Idiomatic naming strategy as opt-in (#679)
### Motivation
Implementation of #683.
### Modifications
- Implemented the SOAR-0013 idiomatic naming strategy
- Added name overrides
- Switched most reference tests to use the new strategy
- Updated some docs (I'll update the rest after this lands and gets
released, then I can update Examples and IntegrationTest)
### Result
SOAR-0013 implemented.
### Test Plan
Updated and added new unit tests.
---------
Co-authored-by: Si Beaumont <simonjbeaumont@gmail.com>
Co-authored-by: Si Beaumont <beaumont@apple.com>

Access properties with explicit self in `encode(to encoder:)` (#699)
### Motivation
In #696 we avoided clashing with a property called `container` in
certain schemas by making use of explicit self in `init(from decoder:)`.
We didn't have access to the OpenAPI document and hadn't caught the case
where this was used in a schema that supported additional properties,
where we also need to avoid the clash in `encode(to encoder:)`.
### Modifications
- Access properties with explicit self in `encode(to encoder:)`.
### Result
- Fixes #695 
### Test Plan
More snippet tests and reference tests.

Add a note about an open issue with code generation and SourceKit-LSP (…
…#642)
Following the discussion on Slack, this adds a note for users of
SourceKit-LSP informing them that the default code generation might not
work as expected and offers a possible workaround.
https://swift-open-source.slack.com/archives/C02PV8T5HQD/p1726815970093299
Only updates documentation. Let me know if you feel this is the right
place for this information?