Introduce an "init" subcommand for bootstrapping a package

[czechboy0]

Introduce an "init" subcommand for bootstrapping a package.

At the very least, should bootstrap (decision: client vs server, asked by the CLI):

• Package.swift
• a new Hello World-like OpenAPI document (or an existing one can be provided by the user in the command)
• main.swift/Tool.swift with the entry point and basic code to get things working with swift run
• config file with reasonable defaults

For example: swift-openapi-generator init-package --mode client would create a new package, with a simple OpenAPI doc, and the generator configured etc. This package would work out of the box with swift run. Just need two variants: client and server.

[simonjbeaumont]

Just need two variants: client and server.

No types?

[czechboy0]

I think splitting types is a more advanced use case where we don't know what to generate for the executable (would there even be an executable?). Client and server are easy, basically our Hello World examples, just with a customizable name etc. But Types might need more thought. But ofc we can include it if we identify a common enough pattern to make it worth it.

[simonjbeaumont]

I was thinking it would generate a library target, without an executable.

Which begs the question: what should we generate for client? I assumed we would generate a library target with package access modifier and an executable, but potentially you thought just an executable?

[czechboy0]

An interesting approach in Swift Lambda v2, init a clean executable package, add the dependency on the CLI, then invoke the command plugin to init: https://github.com/swift-server/swift-aws-lambda-runtime/pull/448/files#diff-243dfb2a5f495c330b335441f8e306d0ba5ce938a8956aeb1cab030b32a62540R71