Add initializer with LambdaHandler directly with Decodable event and Void output

[natanrolnik]

Add convenience initializer for LambdaRuntime to accept LambdaHandler instances with Void output

Motivation:

Following PR #581, which added convenience initializers for LambdaRuntime to accept LambdaHandler instances with Encodable outputs, there was still a gap for handlers that return Void. This is useful, for example, for AWS event sources like SQS, where the AWSLambdaEvents package provides SQSEvent but there's no corresponding output type - handlers simply process messages and return Void.

Without this initializer, developers had to manually wrap their handlers with LambdaCodableAdapter and LambdaHandlerAdapter, which was verbose and inconsistent with the new API (similar to what is described in #581)

Modifications:

1. Added a new init(decoder:handler:) convenience initializer to LambdaCodableAdapter in Lambda+JSON.swift that accepts a JSONDecoder for handlers with Void output.

2. Added a new convenience initializer to LambdaRuntime that accepts a LambdaHandler instance with Void output directly, handling the wrapping internally.

3. Updated documentation comments to distinguish between handlers with Void and Encodable outputs.

Result:

Developers can now initialize LambdaRuntime with handlers that return Void using a clean, direct API. This is especially useful for event sources like SQS:

import AWSLambdaEvents

struct MySQSHandler: LambdaHandler {
    func handle(_ event: SQSEvent, context: LambdaContext) async throws {
        // Process SQS messages
    }
}

let runtime = LambdaRuntime(lambdaHandler: MySQSHandler())

This provides API completeness, matching the convenience initializers for handlers with Encodable outputs, and delivers better ergonomics for common serverless patterns.

[sebsto]

LGTM, thank you for improving the API