Drop spurious limitations section on pay_for_offer

For some time we've automatically opened a connection to the
blinded path introduction point when we need to send a message we
generated. However, the "Limitations" section in
`ChannelManager::pay_for_offer` lists having a direct connection
as required for the payment to succeed, which is not true.

Instead, we simply remove the section from both `pay_for_offer` and
`pay_for_offer_from_human_readable_name`.

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -11185,12 +11185,6 @@ where
 	/// to construct a [`BlindedMessagePath`] for the reply path. For further privacy implications, see the
 	/// docs of the parameterized [`Router`], which implements [`MessageRouter`].
 	///
-	/// # Limitations
-	///
-	/// Requires a direct connection to an introduction node in [`Offer::paths`] or to
-	/// [`Offer::issuer_signing_pubkey`], if empty. A similar restriction applies to the responding
-	/// [`Bolt12Invoice::payment_paths`].
-	///
 	/// # Errors
 	///
 	/// Errors if:
@@ -11405,12 +11399,6 @@ where
 	/// to construct a [`BlindedMessagePath`] for the reply path. For further privacy implications, see the
 	/// docs of the parameterized [`Router`], which implements [`MessageRouter`].
 	///
-	/// # Limitations
-	///
-	/// Requires a direct connection to the given [`Destination`] as well as an introduction node in
-	/// [`Offer::paths`] or to [`Offer::issuer_signing_pubkey`], if empty. A similar restriction applies to
-	/// the responding [`Bolt12Invoice::payment_paths`].
-	///
 	/// # Errors
 	///
 	/// Errors if a duplicate `payment_id` is provided given the caveats in the aforementioned link.