Fix sqlite timestamps

[Sytten]

Fixes #3693
Fixes #3320

This is a big change in the way we store and parse timestamp in sqlite.

• (Major) We don't ignore timezones anymore if they are present, I am unsure why this what put in place but it feels very very very wrong to me. The data written by diesel is always switched to UTC, but we can't assume the data in the database was written by us. We still fallback to a "naive" implementation if the timezone is missing. I had to remove "bad" tests since 1970-01-01 00:00+01:00 is not the same time as 1970-01-01 00:00Z in my book. We still ignore the timezone if the user uses a "naive" datetime to read the data (I think that is fair, though we could verify with other ORM if they correct to UTC instead).
• Uniformity between time and chrono, the code looks more similar and the formats are the same so a user can switch library without any issue now (that was something I found in ToSql<TimestamptzSqlite, Sqlite> is inconsistent between NaiveDateTime and PrimitiveDateTime #3693)
• Fixed some documentation

[weiznich]

Thanks for opening this PR. I've left a bunch of questions and notes for minor improvements. Beside of that I want to clarify an important point: You consider that a minor change, as it does only strictly extend which time formats are parsed and does not error out on formats that worked before?

Additionally I would like to see a few tests for time<->chrono roundtrips just to make sure that they stay consistent in the future.

[Sytten]

@weiznich This is ready for another round of review, I changed a bit the encoding.

I realized we didn't need the differentiation for subsecond in chrono since the dot is handled by the formatter.
I changed time to now print all digits instead of just 3 or 6 like it currently done, this aligns it with chrono (and what sqlx is doing whatever that's worth).

I am still unsure how many digits we should really print, PG and Mysql cut at the microseconds but sqlite by default stops at the millisecond with %f. And if we should differentiate between a datetime with timezone and a "naive" datetime/time. Any external opinion would be appreciated, but it seems all over the place.

The case for printing they all is quite simple, it's still respecting the RFC3339 and the user can decide to not pass us the microseconds/nanoseconds if they don't want them in the database but the inverse (stopping at X digits) means we decide what loss of information is acceptable.

[weiznich]

Thanks for the update and sorry for taking so long to do the review.

I think it's mostly fine now. I would like to change the comments to doc-comments as suggested my @Mingun
I also would like to actually check the values in the compatibility tests to ensure that we load the right thing there.

[Sytten]

@weiznich Ready!

[weiznich]

Thanks 👍