Re-evaluate making date-time formats more flexible

[jyutzler]

The following is from @heidivanparys in #665 (comment):

The GeoPackage format does not fit our needs for an exchange format1 if the datetime data type is limited to exactly three decimals. Many of our datasets contain timestamps with a finer temporal resolution than milliseconds, some datasets contain data with a courser temporal resolution than milliseconds. (Note that for a given column, the values will all have the same temporal resolution.)

Leaving out the extra decimals in a datetime column is of course not an option. That would mean that we would change the data, and that the data we exchange with third parties would be different from the data we have in our own database. For timestamps with fewer decimals, adding one or more zeroes would give a false impression of the temporal resolution.

Putting our timestamps with all the extra decimals in a datetime column gives a GeoPackage file that is not compliant to the current specification. That is not a good option for an organisation that wants to promote the use of and compliance to standards.

Putting our timestamps in text columns is a third, theoretical option, but it is not very user-friendly for those that use GIS applications.

Note again that the SQLite documentation does not mandate exactly three decimals, that is the interpretation in the GeoPackage specification / by the GeoPackage SWG.

1 This means that often, the one receiving the data will not query the GeoPackage file directly, but will load the data in their own database, and query it there, using the datetime functionality of that database.

Now that GeoPackage 1.4 has been released, it is time to revisit this issue. References: #665 #648