refactor BatchStatement routing

[dkropachev]

Follow-up from PR #878 discussion: #878 (comment)

BatchStatement routing metadata is currently inconsistent. The routing key and keyspace are extracted through different code paths, which means a batch can derive the routing key from one child statement and the keyspace from another. If tablet/table routing metadata is added on top of that, the table can also be derived from a third statement.

This creates ambiguity for tablet-aware/token-aware routing because all routing metadata should describe the same routed child statement.

The PR works around this by adding getRoutingStatement(protocolVersion, codecRegistry) and using that statement for tablet routing, but a complete solution needs a broader BatchStatement API refactor. Simply routing everything through getRoutingStatement would force APIs like keyspace/table lookup to accept ProtocolVersion and CodecRegistry, which is not a clean user-facing API.

Suggested scope:

• Define a single internal routing metadata source for BatchStatement.
• Ensure routing key, keyspace, and table are derived from the same child statement.
• Avoid leaking codec/protocol-version details into user-facing metadata accessors where possible.
• Preserve compatibility or provide a clear migration path for existing BatchStatement routing APIs.
• Implement generic public abstract String getTable(); on Statement

[dkropachev]

As @Lorak-mmk suggested in #878 (comment), we better to extract RoutingInfo from Statements to make sure we don't loop over statements BatchStatement again and again.

Another way to solve it would be to just get routing info from first statement only.