0.3.0 updates

[Michael-A-McMahon]

Preparing for a 0.3.0 release.

README is updated with changes made since 0.2.0

pom.xml is updated with the 0.3.0 version number, and with a 21.3 dependency for Oracle JDBC (this will be released before 0.3.0)

module-info.java is updated with the new automatic module name for Oracle JDBC

Updated the generated keys test to work with 21.3 Oracle JDBC (invalid column names are no longer detected when Connection.prepareStatement(String, String[]) is called). All other tests are passing with the latest 21.3 build.

OracleConnectionFactoryImpl will reject the unsupported LOCK_WAIT_TIMEOUT Option.

[Michael-A-McMahon]

I marked this PR as a draft with the intent that it not be merged until Oracle JDBC 21.3 is available.

[Michael-A-McMahon]

New commits have Statement.execute() Publisher avoid calling JDBC APIs after emitting a Result. This can resolve an issue where user code maps a Result into another Statement execution, as in:

Flux.from(statement.execute())
  .flatMap(result -> 
    result.map(row -> businessLogic(row.get(0))
  .flatMap(businessValue -> 
    connection.createStatement(...sql...)
      .bind(businessValue)
      .execute());

When that 2nd statement is executed with the businessValue bind, the JDBC connection is locked until the asynchronous execution completes. When the asynchronous execution does complete, a thread must be available to execute JDBC's completion handler that will unlock the connection.
If Oracle R2DBC is making JDBC API calls after emitting a Result, and the JDBC connection is locked for asynchronous execution, this means that Oracle R2DBC is going to block a thread. If Oracle R2DBC blocks enough threads, then no threads are left to execute JDBC's callback and the system becomes deadlocked.

The latest commits will eliminate cases where java.sql.Statement methods like getMoreResults, getLargeUpdateCount, or close would be called after emitting the Result.