Document the cap on the number of offers that can be matched by a single transaction

[intelliot]

The payment engine has a limit of 1000 offers that can be crossed (matched) by any single transaction. If any transaction attempts to process over 1000 offers, the transaction consumes the liquidity from the first 1000 offers, and then continues with processing the transaction without considering any other offers in that particular order book. This is a remarkable behavior which has potential implications that traders must consider when trying to understand what their offers may do, especially since a trader generally has no control over the number of counterparties' offers that may be matched.

See: https://github.com/XRPLF/rippled/blob/40b4adc9cc296a7e3c6e8c94b5a977a54c835613/src/ripple/app/tx/impl/CreateOffer.h#L41

[joynancy]

Additionally, it would be beneficial if xrpl.org could provide guidance on best practices for handling large-volume orders (exceeding 1000) when mentioning the limit of 1000 offers.

Take this x.com post as a reference: https://x.com/angell_denis/status/1792208779976507573, it suggested trader to use the tfImmediateOrCancel or FillOrKill flag.
I see these two flags were explained here https://xrpl.org/docs/references/protocol/transactions/types/offercreate/, suggest to take this opportunity to guide the use case of these two flags.