Fix docs on timezone of naive date(time) strings

[soxofaan]

Addresses the documentation issue raised in #257:
passing a naive date string to travel will be interpreted as local time

[adamchainz]

That isn’t a documentation issue, the current behaviour is indeed to intepret as UTC...?

[soxofaan]

The current behavior of passing something like destination="2022-02-20" is to interpret as local time (see the added tests), the documentation states otherwise (interpret as UTC).
So there is at least a bug in one of:

• the implementation
• the documentation

This PR fixes the documentation (which is the easiest option)

[Siburg]

Just found same issue today, after replacing freezegun with time_machine. I was actually quite pleased to see that a string was interpreted as being for the timezone in my settings. Made my tests more readable in my opinion. But I was subsequently surprised that the documentation indicates something different. So I support updating the documentation, and leaving functionality as-is.

[adamchainz]

Thank you for the docs patch.