Revert streaming codable handler and provide it as an example, not an API

[sebsto]

Revert streaming codable handler change and propose it as an example instead of an handler API.

Motivation:
I made a mistake when submitting this PR
#532

It provides a Streaming+Codable handler that conveniently allows developers to write handlers with Codable events for streaming functions.

This is a mistake for three reasons:

• This is the only handler that assumes a Lamba Event structure as input. I added a minimal FunctionUrlRequest and FunctionURLResponse to avoid importing the AWS Lambda Events library. It is the first handler to be event-specific. I don't think the runtime should introduce event specific code.

• The handler only works when Lambda functions are exposed through Function URLs. Streaming functions can also be invoke by API or CLI.

• The handler hides FunctionURLRequest details (HTTP headers, query parameters, etc.) from developers

Developers were unaware they were trading flexibility for convenience

The lack of clear documentation about these limitations led to incorrect usage patterns and frustrated developers who needed full request control or were using other invocation methods.

Modifications:

• Removed the Streaming+Codable API from the library
• Moved the Streaming+Codable code to an example
• Added prominent warning section in the example README explaining the limitations
• Clarified when to use Streaming+Codable vs ByteBuffer approaches
• Added decision rule framework to help developers choose the right approach

Result:
The only API provided by the library to use Streaming Lambda functions is exposing the raw ByteBuffer as input, there is no more Codable handler for Streaming functions available in the API. I kept the Streaming+Codable code an example.

After this change, developers have clear guidance on when to use each streaming approach:

• Use streaming codable for Function URL + JSON payload + no request details needed
• Use ByteBuffer StreamingLambdaHandler for full control, other invocation methods, or request metadata access

This prevents misuse of the API and sets proper expectations about the handler's capabilities and limitations, leading to better developer experience and fewer integration issues.

[sebsto]

Simplify the Streaming+Codable adapter code when swift-server/swift-aws-lambda-events#90 will be merged