align naming of QueryOptions/StatementOptions with new Query/Statement distinction

[gavinking]

See #806.

[gavinking]

I believe this one should just be merged. Any objections??

[njr-11]

I'm not sure these names are an improvement over what we already had. I suppose it depends on what we see as the more dominant use case for them.

If we were only considering Jakarta Data, the term Statement doesn't have a particular meaning. Some users might think of java.sql.Statement, which is a common to queries that perform find operations as well as deletes and updates and even insert. In Jakarta Data, UPDATE and DELETE are performed by @Query, @StaticQuery, and @StaticNativeQuery which fit nicely with the existing @WriteQueryOptions (or @ReadQueryOptions if instead a SELECT query). The position from Jakarta Data should be that existing names are a very good fit, and a change to @StatementOptions and @TypedQueryOptions do not match up with existing terminology in the spec, lessening the usability.

Considering Jakarta Persistence, the alignment with new API classes there makes more sense.

I'm probably biased, but I would opt for the better alignment with Jakarta Data here.

[gavinking]

Hrmph OK I had not looked at it like that.

I don't have a useful response right now, let me think it over.