Read a naive RELATIVE_BASE in the parsed date's timezone

[AdrianAtZyte]

Fixes #927, fixes #1156

[codspeed]

Merging this PR will not alter performance

✅ 7 untouched benchmarks

---

_{Comparing AdrianAtZyte:relative-base-timezone (ec5dd40) with master (4574502)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.95%. Comparing base (4574502) to head (ec5dd40).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1439   +/-   ##
=======================================
  Coverage   98.94%   98.95%           
=======================================
  Files         239      239           
  Lines        3513     3538   +25     
=======================================
+ Hits         3476     3501   +25     
  Misses         37       37           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[serhii73]

Thanks for untangling this; an aware RELATIVE_BASE and the no-RELATIVE_BASE case clearly work better now. For
example, '10:30' with an aware UTC base and TIMEZONE='America/New_York' used to return None. #1156 is fixed too.

My concern is a naive RELATIVE_BASE with default settings. Because it is now read in TIMEZONE, which defaults to the
machine's local zone, and then converted to the string's zone, a date-only base moves US-zone times to the previous day, and a
pinned base no longer gives machine-independent results:

from datetime import datetime
import dateparser

dateparser.parse('10:04am EDT', settings={'RELATIVE_BASE': datetime(2020, 7, 19)})
# master: 2020-07-19 10:04-04:00 (any machine TZ)
# PR:     2020-07-18 10:04-04:00 (any machine TZ)

dateparser.parse('9pm UTC', settings={'RELATIVE_BASE': datetime(2020, 7, 19)})
# master: 2020-07-19 21:00+00:00 (any machine TZ)
# PR:     2020-07-19 with TZ=UTC, 2020-07-18 with TZ=Europe/Warsaw or Asia/Tokyo

The first one is the long-standing test_time_without_date_should_use_today, which the PR rewrites instead of keeping.
Passing a date as RELATIVE_BASE (e.g. a page's publication date) and parsing "10:30 AM EST" is a common pattern, so I would
rather not change it silently. The title's wording, a naive base read "in the parsed date's timezone", would actually keep it
on 07-19.

It also reverses #1092, whose test the PR flips:

dateparser.parse('6pm', settings={
    'PREFER_DATES_FROM': 'future', 'TO_TIMEZONE': 'etc/utc', 'RETURN_AS_TIMEZONE_AWARE': False,
    'RELATIVE_BASE': datetime(2022, 11, 6, 22, 0), 'TIMEZONE': 'america/new_york'})
# master: 2022-11-06 23:00 (what #1092 asked for); PR: 2022-11-07 23:00

Could we keep the unambiguous parts (the current time taken in the right zone, and an aware base converted) and leave a naive
base as it is read today? Or at least interpret a naive base in TIMEZONE only when TIMEZONE is set explicitly? That still
fixes #1156 and keeps default-settings results stable. We would then need to decide separately what to do about #1092's case.
Also, this overlaps with #1427 (same tz plumbing), so it would help to land one on top of the other.