GH-1409: Fix Nacks for Async Replies

Resolves https://github.com/spring-projects/spring-amqp/issues/1409

Normally, when message has a fatal exception (such as message conversion)
`basicNack` with `multiple` true is used, to nack any previously unacked
messages (e.g. when using batch size to limit the ack traffic).
Even when using manual acks, fatal exceptions are nacked by the container
because the user does not have access to the message.

However, when using async replies, this has the side effect of nacking
unprocessed messages.

Detect whether async replies are being used and only nack individual
records that cause fatal exceptions.

Also, coerce the `AcknowledgeMode` to `MANUAL` for such listners.

Add a test for both containers; send a good message followed by a
bad one without actually completing the reply future.
After the exception occurs and the container is stopped, there should
be one messag in the queue.

* Remove warning, deprecation; add docs.

* Docs.

**Cherry-pick to `2.3.x` & `2.2.x`**

src/reference/asciidoc/amqp.adoc

@@ -3535,6 +3535,9 @@ If the async result is completed with an `AmqpRejectAndDontRequeueException`, th
 If the container's `defaultRequeueRejected` property is `false`, you can override that by setting the future's exception to a `ImmediateRequeueException` and the message will be requeued.
 If some exception occurs within the listener method that prevents creation of the async result object, you MUST catch that exception and return an appropriate return object that will cause the message to be acknowledged or requeued.
 
+Starting with versions 2.2.21, 2.3.13, 2.4.1, the `AcknowledgeMode` will be automatically set the `MANUAL` when async return types are detected.
+In addition, incoming messages with fatal exceptions will be negatively acknowledged individually, previously any prior unacknowledged message were also negatively acknowledged.
+
 [[threading]]
 ===== Threading and Asynchronous Consumers