[FlightSQL] Clearly clarify the behavior of the CommandPreparedStatementUpdate in doc

We found that arrow-go and arrow-rs have different implementations for the prepared statement's `execute_update` interface.

Rust's implementation breaks the execution into two stages. First, it uses `CommandPreparedStatementQuery` to send parameter binding to the server. Then, it uses `CommandPreparedStatementUpdate` to notify the server to execute the prepared statement.
You can find the codes in: https://github.com/apache/arrow-rs/blob/522bd012f1b92419d9832180b609b0caf9fff35c/arrow-flight/src/sql/client.rs#L577-L599

Go's implementation, however, only has one stage. It uses `CommandPreparedStatementUpdate` to send parameter binding along with notifying the server to execute the prepared statement.
You can find the codes in: https://github.com/apache/arrow-go/blob/c124ae4449d8cb249bb870cd7a3c533f6ca17434/arrow/flight/flightsql/client.go#L1195-L1247

It seems both implementations are okay since the protocol does not clearly clarify the behavior of the CommandPreparedStatementUpdate. See: https://arrow.apache.org/docs/format/FlightSql.html#query-execution

However, due to the inconsistency in their implementations, our server needs to handle both scenarios. Specifically, the server must additionally check in the `do_put_statement_update` implementation whether the client has written parameter bindings. Our initial implementation didn’t perform such checking, causing issues with multi-language integration.

Therefore, I suggest that Arrow clarify the behavior of the `CommandPreparedStatementUpdate` interface in its documentation, especially regarding whether parameter bindings can be transmitted through this interface.

Start with the Flight SQL query execution documentation and compare the linked arrow-rs and arrow-go client implementations of CommandPreparedStatementUpdate. Document whether parameter bindings may be sent through this interface and clarify the expected execution behavior so servers can handle both client patterns.

Written by the indexing model from the issue text.