enhance request handling with NFData instances

[kushagarr]

@endgame this should close #523. Do let me know if you think this is not a correct way of solving the issue

[kushagarr]

@endgame could you please take a look and let me know if this is moving in right direction ?

[endgame]

I'm not convinced that it's right but I'm also not convinced that it's wrong. For a subtle laziness issue like this we need to replicate it first, and then prove that the PR fixes it.

This probably means standing up some temporary lambda infrastructure to make requests against.

I would probably also consider the strict-wrapper package, but it might be impossible to maintain the interface we currently expose.

[kushagarr]

Here is the gist of the changes: (Generated with AI)

• Response evaluation is request-specific through AWSRequest.evaluateResponse.
• The default evaluates only the outer constructor, preserving streaming responses and handwritten instances without NFData.
• Generated non-streaming operations override the policy with rnf; generated streaming operations retain the shallow default.
• Evaluation is centralized in Amazonka.HTTP, so signed/unsigned sends, retries, pagination, and waiters behave consistently.
• The post-hook request is used when selecting the policy.
• Successful waiter responses are evaluated before acceptors; failed responses are not evaluated.
• Response hooks run before evaluation.
• Evaluation exceptions propagate through IO and are not converted to Amazonka.Error.

The handwritten S3 encryption wrappers were also audited:

• Encrypted a delegates to the wrapped request policy.
• PutInstructions and DeleteInstructions deeply evaluate their non-streaming responses.
• Streaming decryption responses remain shallow.

The expanded regression coverage now includes discarded signed and unsigned sends, request hooks, response-hook ordering, retries, pagination, waiter retries, parse failures, streaming body readability, and encrypted request wrappers.

Validation completed:

• 16 amazonka tests pass.
• 6 amazonka-s3-encryption tests pass.
• Fresh S3 and DynamoDB generation and compilation pass.
• Every DynamoDB operation and every non-streaming S3 operation receives the deep policy.
• S3 GetObject and GetObjectTorrent retain the streaming-safe shallow policy.
• Representative S3, DynamoDB, SQS, generator, and encryption builds pass.
• HLint, Ormolu, and whitespace checks pass.

This keeps the public streaming interface intact while ensuring ordinary parsed responses are fully evaluated at the request boundary, even when callers discard the returned value.

@endgame I would appreciate another look at the final approach.