getDate, getTime, getTimestamp, and the java.time getObject targets do not follow SQLite storage classes #102

The date and time getters call getString() and then Date.valueOf, Time.valueOf, or Timestamp.valueOf. On failure they try Long.parseLong and otherwise return null. The LocalDate, LocalTime, and LocalDateTime targets parse substrings of the text.

sqlite-jdbc branches on the storage class instead. INTEGER is epoch time, REAL is a Julian day, and TEXT uses the yyyy-MM-dd HH:mm:ss.SSS format.

Differences:

• TEXT '2024-01-02 10:00:00'. getDate and getObject(Date.class) return null. getTime returns null. sqlite-jdbc returns 2024-01-02.
• INTEGER 1700000000000. getObject(LocalDate.class), getLocalTime, and getLocalDateTime throw Bad value. sqlite-jdbc returns 2023-11-14. getTime has no integer fallback.
• REAL. A Julian day returns null or throws.

A silent null for a valid datetime string is the worst case. The Javadoc table added in #69 says these targets match sqlite-jdbc, which is not true for these inputs.

Expected:

• Switch on the Value type for each getter and build the java.time targets from that result.
• Add tests for TEXT, INTEGER, and REAL inputs on every date and time getter and target.