dealing with y2k38

**Describe the problem you have/What new integration you would like**

esphome timekeeping uses Unix epoch time as a signed 32-bit integer. That will roll over and become negative in 2038. I have a project that will be permanently installed in a house, and operating for more than 20 years is a real possibility. I'd like to not worry about Y2K38 (or have some future homeowner who knows nothing about this having to worry about how to fix it).

**Please describe your use case for this integration and alternatives you've tried:**

The problem is that signed 32 bit integer in traditional Unix timekeeping. Many alternatives have come along in the computer industry (for example, an unsigned 32 bit integer, or any kind of 64 bit integer), some of which might be suitable for use in esphome. I'm not too fussy about which implementation might be used. I just don't want to clutter up my project's configuration with a bunch of extra arithmetic to deal with it.

**Additional context**

"The future Future FUTURE!!! ..." :-)

Start by locating ESPHome's timekeeping implementation and all uses of signed 32-bit Unix epoch values. The request names no files or tests, so the relevant entry points and affected platforms must first be identified. Done means timekeeping remains usable beyond the 2038 rollover without project-specific arithmetic.

Written by the indexing model from the issue text.