GH-62: Optimize Flight SQL JDBC Statement execution paths

[xborder]

What Changed

• This change simplifies the Flight SQL JDBC request flow for Statement.executeQuery/executeUpdate avoiding the PreparedStatement request flow
• Preserved the current requirement that Statement.execute(String) still flows through PreparedStatement
  • Right now, Arrow Flight does not offer a good solution for this use case. There is no way for the client to disambiguate between a CommandStatementUpdate or CommandStatemenQuery without doing a server call
• Moved prepared-statement-specific creation and execution concerns into ArrowFlightPreparedStatement
• Similarly, created ArrowFlightStatement with specific logic to handle Statements
• Removed statement/prepared-statement construction details and logic from ArrowFlightMetaImpl. ArrowFlightMetaImpl was left it focused on orchestration

Closes #62.

This PR was assisted by AI

[ennuite]

Perhaps a nitpick, but if we run multiple queries with the same statement using execute we will only close one of the handles in the server.

Code for repro:

    try (Connection connection = DriverManager.getConnection(jdbcUrl, properties);
         Statement statement = connection.createStatement()) {

      for (int i = 1; i <= n; i++) {
        String sql = "SELECT " + i;
        log("Executing: " + sql);

        boolean isResultSet = statement.execute(sql);
        if (isResultSet) {
          try (ResultSet rs = statement.getResultSet()) {
            // consume result set
          }
        } else {
          System.out.println("Updated rows: " + statement.getUpdateCount());
        }
      }
    }

A new prepared statement will be created on each query, but only one ClosePreparedStatement is sent to the server. I believe most Flight SQL servers are stateless and this won't be problematic in that scenario, but in case the server is holding some resources associated with the handle(s) of the prepared statement(s) that aren't closed there will be a leak.

Could we send the close after execution?

[xborder]

Good catch. This issue existed before the refactor. I've created #1129 to be addressed separately