Add 'LifecycleCommand' integration with ArgumentParser

[slashmo]

Motivation:

Oftentimes when using ServiceLifecycle it's also beneficial to use 'ArgumentParser' to build a CLI for a server-side app, running as part of ServiceLifecycle.

Modifications:

A new 'LifecycleCommand' library target adds integration with 'ArgumentParser'.

Result:

Users can now define their 'ArgumentParser' command and lifecycle as one struct, enabling them to define a unified entry-point for their applications. With Swift >= 5.4 this entry-point can also be decorated with @main.

Use-Case Example

The following example demonstrates how an application entry-point could look like using the new ServiceCommand:

import LifecycleCommand
import Logging

@main
struct App: ServiceCommand {
    @Option
    private var host: String = "localhost"

    @Option
    private var port: UInt = 8000

    @Option
    private var databaseHost: String = "localhost"

    @Option
    private var databasePort: UInt = 5432

    static let logger = Logger(label: "example")

    func bootstrap() throws {
        LoggingSystem.bootstrap { label in
            var handler = StreamLogHandler.standardOutput(label: label)
            handler.logLevel = .debug
            return handler
        }
    }

    func configure(_ lifecycle: ServiceLifecycle) throws {
        let database = Database(host: databaseHost, port: databasePort, logger: Self.logger)
        lifecycle.register(label: "db", start: .async(database.start), shutdown: .async(database.shutdown))

        let server = Server(host: host, port: port, logger: Self.logger)
        lifecycle.register(label: "server", start: .async(server.start), shutdown: .async(server.shutdown))
    }
}

• Closes #29

[slashmo]

@ktoso & @tomerd I started poking around with how this (#29) could look like. I'm quite happy with the end result already but don't love the naming.

[FranzBusch]

@slashmo This PR is outdated now. I think we should not provide a lifecycle and argument parser combination out of the box since this brings the argument parser dep to every adopter. With the new version of service lifecycle we expect libraries to adopt it as well and most of them don't want to depend on argument parser.

If you still see value in this I would be interested in how you would envision it working with the new APIs.

[slashmo]

@FranzBusch Agreed that this is not desired anymore 👍