Review and improve types for dates/datetimes

[asmecher]

Describe the bug
Historically we've used a mix of ints (UNIX epoch timestamps) and strings (parsable date representations, usually converted with strtotime) for date/datetime data in PHP.

Now that we're adopting more Laravel / Eloquent, and now that PHP has better support for DateTime/DateTimeImmutable types, and now that we're adding typehinting, it's time to pick a lane and use it consistently.

(This will require some investigation and thought, both in what specific choices we make and in how it's rolled out. Ideas welcome.)

[asmecher]

Patterns that are good (in my opinion):

• Eloquent attributes have explicit casts to datetime
• Interaction with Eloquent attributes uses Carbon

Patterns that are bad:

• strtotime and manual math on date/datetime content
• Old-style getters without typehinting, returning string representations of dates (I'd prefer a Carbon return -- this should go away with #10188)

[jonasraoni]

I'm all for using the classes wherever possible, it's just needed to have some attention when dealing with different time zones.
I mean, a user inputting 2024-07-31T00:00:00+00:00 and another 2024-07-31T00:00:00+12:00, shouldn't lead to 2024-07-31 00:00:00 in the database.

Another thing to think, not related with this task is allowing the user to setup its time zone or to make it clear which time zone is being used on the system.

[jonasraoni]

As MySQL doesn't support storing dates with time zones, we need to ensure they are converted to the system time zone when storing it.